oauth2在web系统中的应用
<h1 id="前言">前言</h1><p>在日常开发中，系统常需作为对接方或被对接方与其他系统集成。此类集成的首要环节通常是身份认证，其中 OAuth 2.0 认证尤为常见。本文旨在略过繁杂的定义与规范解读，聚焦两个典型应用场景，阐述 OAuth 2.0 的落地设计思路。</p>
<h1 id="单点登录-single-sign-on-sso">单点登录 (Single Sign-On, SSO)</h1>
<p>单点登录场景通常采用 <strong>授权码模式 (Authorization Code Grant)</strong>。该模式的核心在于用户授权后，系统方可获取其登录信息。授权过程既可以是显式的（需要用户确认），也可以是隐式的（无需用户感知）。</p>
<ul>
<li><strong>显式授权示例</strong>：登录某游戏微信公众号进行日常签到，需用户在弹出的授权窗口明确确认。</li>
<li><strong>隐式授权示例</strong>：某集团OA系统集成独立的财务子系统，用户从平台跳转至财务系统即可操作，无需二次登录或确认。</li>
</ul>
<p>以下以 <strong>平台方为业务大平台，为第三方应用提供单点登录接入能力</strong> 为例进行说明（若角色互换为应用接入其他平台，设计思路类同）：</p>
<ol>
<li><strong>应用注册</strong>：
<ul>
<li>平台方需预先存储待接入应用的信息，包括：应用名称、唯一标识应用的 <strong>应用密钥 (App Key 和 Secret)</strong>、以及应用回调地址（用于接收授权码的重定向地址）。</li>
</ul>
</li>
<li><strong>获取授权码 (Authorization Code)</strong>：
<ul>
<li>用户在平台内点击跳转至目标应用。平台将生成一个与该用户绑定的、具有时效性（通常为5-10分钟）的授权码 <code>code</code>，并附加在跳转地址中传递给应用。</li>
<li>该 <code>code</code> 通常为一次性使用且过期失效。可将其作为键（Key），用户信息作为值（Value）存储于 Redis 等缓存中，并设置自动过期策略。</li>
</ul>
</li>
<li><strong>获取访问凭据 (Access Token)</strong>：
<ul>
<li>应用使用接收到的 <code>code</code>，结合其自身的 App Key 和 Secret 向平台认证服务发起请求，换取访问凭据 (Access Token)。</li>
<li>换取成功后，<code>code</code> 立即失效。应用可将用户信息与该 Token 绑定存储于缓存中。</li>
<li>Token 本身通常也具备有效期（例如8至24小时），部分系统提供 Token 刷新接口以延长有效期。</li>
</ul>
</li>
<li><strong>获取用户信息</strong>：
<ul>
<li>应用凭借有效的 Access Token 即可调用平台提供的接口获取用户基本信息（如用户ID、用户名等，具体范围视需求而定）。</li>
<li>若涉及敏感数据，可在应用注册阶段约定加密密钥，对传输数据进行加密处理。</li>
</ul>
</li>
<li><strong>获取扩展信息</strong>：
<ul>
<li>对于网站注册类应用，获取基础用户信息通常已足够。</li>
<li>对于类似OA的管理系统集成，则需平台额外提供获取组织架构信息（如租户、部门、人员、角色及其关系等）的接口，以支撑业务流程对接。</li>
</ul>
</li>
</ol>
<h1 id="数据共享-api-集成">数据共享 (API 集成)</h1>
<p>数据共享场景通常采用 <strong>客户端模式 (Client Credentials Grant)</strong>。此模式允许应用直接使用其 App Key 和 Secret 换取访问凭据，从而访问授权范围内的资源接口，省略了获取用户授权码的步骤。</p>
<p>以下以 <strong>集成 API 开放平台为用户提供不同数据资源</strong> 为例进行说明：</p>
<ol>
<li><strong>应用注册</strong>：
<ul>
<li>在平台注册应用信息，明确勾选该应用有权访问的数据资源（即对应的API接口）。</li>
<li>平台自动生成用于标识该应用的 App Key 和 Secret。</li>
</ul>
</li>
<li><strong>获取访问凭据 (Access Token)</strong>：
<ul>
<li>应用直接使用其 App Key 和 Secret 向平台认证服务发起请求，换取访问凭据。</li>
<li>该 Token 与应用绑定，其访问权限严格限定于注册时勾选的资源接口范围。</li>
</ul>
</li>
<li><strong>访问资源接口</strong>：
<ul>
<li>应用在调用授权的资源接口时，需在请求头部（如 <code>Authorization</code> 头）携带有效的 Access Token 进行认证。</li>
<li>平台可根据注册的应用信息实施访问控制策略，例如限制接口调用频率或单次请求的数据量上限。</li>
</ul>
</li>
</ol><br><br>
来源：https://www.cnblogs.com/yanpeng19940119/p/18961591
頁:
[1]