oauth2在web系统中的应用

在日常开发中，系统常需作为对接方或被对接方与其他系统集成。此类集成的首要环节通常是身份认证，其中 OAuth 2.0 认证尤为常见。本文旨在略过繁杂的定义与规范解读，聚焦两个典型应用场景，阐述 OAuth 2.0 的落地设计思路。

单点登录场景通常采用 授权码模式 (Authorization Code Grant)。该模式的核心在于用户授权后，系统方可获取其登录信息。授权过程既可以是显式的（需要用户确认），也可以是隐式的（无需用户感知）。

• 显式授权示例：登录某游戏微信公众号进行日常签到，需用户在弹出的授权窗口明确确认。
• 隐式授权示例：某集团OA系统集成独立的财务子系统，用户从平台跳转至财务系统即可操作，无需二次登录或确认。

以下以 平台方为业务大平台，为第三方应用提供单点登录接入能力 为例进行说明（若角色互换为应用接入其他平台，设计思路类同）：

1. 应用注册：
   • 平台方需预先存储待接入应用的信息，包括：应用名称、唯一标识应用的 应用密钥 (App Key 和 Secret)、以及应用回调地址（用于接收授权码的重定向地址）。
2. 获取授权码 (Authorization Code)：
   • 用户在平台内点击跳转至目标应用。平台将生成一个与该用户绑定的、具有时效性（通常为5-10分钟）的授权码 code，并附加在跳转地址中传递给应用。
   • 该 code 通常为一次性使用且过期失效。可将其作为键（Key），用户信息作为值（Value）存储于 Redis 等缓存中，并设置自动过期策略。
3. 获取访问凭据 (Access Token)：
   • 应用使用接收到的 code，结合其自身的 App Key 和 Secret 向平台认证服务发起请求，换取访问凭据 (Access Token)。
   • 换取成功后，code 立即失效。应用可将用户信息与该 Token 绑定存储于缓存中。
   • Token 本身通常也具备有效期（例如8至24小时），部分系统提供 Token 刷新接口以延长有效期。
4. 获取用户信息：
   • 应用凭借有效的 Access Token 即可调用平台提供的接口获取用户基本信息（如用户ID、用户名等，具体范围视需求而定）。
   • 若涉及敏感数据，可在应用注册阶段约定加密密钥，对传输数据进行加密处理。
5. 获取扩展信息：
   • 对于网站注册类应用，获取基础用户信息通常已足够。
   • 对于类似OA的管理系统集成，则需平台额外提供获取组织架构信息（如租户、部门、人员、角色及其关系等）的接口，以支撑业务流程对接。

数据共享场景通常采用 客户端模式 (Client Credentials Grant)。此模式允许应用直接使用其 App Key 和 Secret 换取访问凭据，从而访问授权范围内的资源接口，省略了获取用户授权码的步骤。

以下以 集成 API 开放平台为用户提供不同数据资源 为例进行说明：

1. 应用注册：
   • 在平台注册应用信息，明确勾选该应用有权访问的数据资源（即对应的API接口）。
   • 平台自动生成用于标识该应用的 App Key 和 Secret。
2. 获取访问凭据 (Access Token)：
   • 应用直接使用其 App Key 和 Secret 向平台认证服务发起请求，换取访问凭据。
   • 该 Token 与应用绑定，其访问权限严格限定于注册时勾选的资源接口范围。
3. 访问资源接口：
   • 应用在调用授权的资源接口时，需在请求头部（如 Authorization 头）携带有效的 Access Token 进行认证。
   • 平台可根据注册的应用信息实施访问控制策略，例如限制接口调用频率或单次请求的数据量上限。