1. OAuth2 协议基础：四种授权模式核心流程与适用场景

OAuth2 是当前业界最主流的授权框架，它通过 令牌（Access Token） 代替用户名/密码在第三方应用与资源服务器之间传递身份与权限。理解四种授权模式是进行安全审计与尾延迟压测的前提——不同模式在握手次数、令牌传输路径、刷新策略上差异显著，直接影响压测的并发模型与延迟分布。

1.1 四种授权模式总览

授权模式 核心参与者 令牌获取方式 典型场景 安全等级
授权码模式 用户、浏览器、授权服务器、客户端、资源服务器 授权码 → 令牌（两步交换） Web 服务端应用（有后端） ★★★★★
隐式模式 用户、浏览器、授权服务器、客户端（JS） 直接返回令牌（Fragment） 纯前端 SPA（已逐步淘汰） ★★☆☆☆
密码模式 用户、客户端、授权服务器 用户名+密码 → 令牌 第一方应用、信任客户端 ★★★☆☆
客户端凭证模式 客户端、授权服务器 客户端凭证 → 令牌 服务间通信、后台任务 ★★★★☆
压测视角提示： 授权码模式因包含两次 HTTP 交换（授权码 + 令牌），在并发场景下授权服务器承受的请求量是其他模式的 2 倍；密码模式虽然握手最少，但涉及敏感凭证传输，安全审计要求更高。

1.2 授权码模式（Authorization Code）

授权码模式是 OAuth2 中最完整、最安全的模式，也是压测诊断课程的核心研究对象。其流程包含 5 个步骤，其中步骤 2 和步骤 4 是压测的关键延迟点。

  1. 用户访问客户端：用户通过浏览器访问第三方应用，触发登录/授权请求。
  2. 客户端重定向至授权服务器：客户端将用户浏览器重定向到授权服务器的 /authorize 端点，携带 response_type=code、client_id、redirect_uri、scope。
  3. 用户认证并授权：用户在授权服务器上输入凭证，确认授权范围。
  4. 授权服务器返回授权码：授权服务器通过重定向将 授权码（code） 发送到客户端的 redirect_uri。
  5. 客户端换取令牌：客户端使用授权码 + client_secret 向授权服务器的 /token 端点发起 POST 请求，获取 Access Token 和 Refresh Token。
授权码模式核心流程 用户浏览器 客户端应用 授权服务器 资源服务器 ① 访问 ② 重定向 /authorize ③ 用户认证并授权 ④ 返回授权码 ⑤ POST /token 换取 Access Token 使用 Access Token 请求资源 压测关注点： • 步骤 ② 和 ⑤ 是两次独立的 HTTP 请求，授权服务器需处理 2 倍于其他模式的请求量。 • 步骤 ⑤ 的 /token 端点通常涉及数据库查询（验证授权码、生成令牌），是尾延迟的主要来源。

1.3 隐式模式（Implicit）

隐式模式是授权码模式的简化版，授权服务器直接通过 URL Fragment（#access_token=...）返回令牌，省略了授权码交换步骤。该模式因令牌暴露在浏览器历史记录和 Referer 头中，安全风险较高，OAuth2 Security BCP 已建议逐步淘汰。

  • 流程简化：用户认证后，授权服务器直接返回 Access Token（无授权码）。
  • 适用场景：纯前端单页应用（SPA），无后端服务配合。
  • 压测特点：单次握手即可获取令牌，但无法使用 Refresh Token，令牌过期后需重新认证。
安全警告： 隐式模式不支持客户端认证，令牌可能被恶意脚本窃取。在压测诊断课程中，我们仅将其作为对比基线，不推荐在生产环境中使用。

1.4 密码模式（Resource Owner Password Credentials）

密码模式允许客户端直接使用用户的用户名和密码换取令牌，仅适用于高度信任的客户端（如官方第一方应用）。该模式在压测中容易造成凭证泄露风险，且不支持细粒度的授权范围协商。

// 密码模式令牌请求示例
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=password
&username=user@example.com
&password=secret123
&client_id=my_client
&client_secret=my_secret
对比维度 授权码模式 密码模式
凭证传输 用户凭证仅与授权服务器交互 用户凭证暴露给客户端
令牌刷新 支持 Refresh Token 通常不支持（需重新认证）
压测并发模型 需模拟两次请求（code + token） 单次请求即可获取令牌
安全审计复杂度 高（需审计授权码生命周期） 低（但凭证泄露风险高）

1.5 客户端凭证模式（Client Credentials）

客户端凭证模式是四种模式中最简洁的一种，客户端使用自己的 client_id 和 client_secret 直接获取令牌，不涉及用户参与。该模式常用于微服务之间的内部通信、定时任务或后台数据同步。

  1. 客户端认证：客户端向授权服务器的 /token 端点发送 grant_type=client_credentials 及自身凭证。
  2. 授权服务器验证：验证客户端身份和权限范围。
  3. 返回令牌：授权服务器返回 Access Token（通常无 Refresh Token）。
客户端凭证模式流程 客户端服务 （微服务/后台任务） 授权服务器 （令牌颁发） 资源服务器 （API） ① POST /token client_credentials ② 返回 Access Token ③ 使用 Token 调用 API 压测特点： 无用户交互，令牌获取延迟仅取决于授权服务器性能；适合高并发压测，但需注意令牌缓存策略避免重复请求。

1.6 四种模式对比与压测选型建议

模式 HTTP 交换次数 令牌可刷新 用户参与 压测复杂度 推荐压测场景
授权码 2 次（code + token） 是 是 高 Web 应用全链路压测
隐式 1 次 否 是 低 SPA 性能基线（已淘汰）
密码 1 次 通常否 是 中 第一方应用登录压测
客户端凭证 1 次 视配置 否 低 微服务间通信压测
← 上一章 📖 返回目录 下一章 →