1. OAuth2 协议核心概念：四种授权模式对比

OAuth2 是当前业界最主流的授权框架，定义了四种授权模式以适应不同客户端场景。理解这四种模式的区别，是后续设计限流策略与诊断尾延迟的基础。本节从流程、适用场景、安全属性三个维度进行对比。

1.1 四种模式核心流程对比

授权模式 核心参与者 令牌获取方式 是否暴露令牌给用户代理 典型场景
授权码模式 资源所有者、用户代理、授权服务器、客户端 授权码 → 令牌 否（授权码经后端交换） Web 服务端应用、有后端的 SPA
客户端模式 客户端、授权服务器 直接凭客户端凭证换取 不涉及用户 服务间调用、后台任务、API 网关
资源所有者密码凭证模式 资源所有者、客户端、授权服务器 用户名 + 密码直接换取 是（客户端直接持有密码） 遗留系统迁移、高度信任的第一方应用
隐式模式 资源所有者、用户代理、授权服务器 直接返回令牌（无授权码） 是（令牌在 URL 片段中） 纯前端应用（已逐步被授权码 + PKCE 取代）
性能工程视角： 授权码模式因多一次后端交换（授权码 → 令牌），在限流策略中需对 /authorize 和 /token 两个端点分别设置阈值；客户端模式仅涉及 /token 端点，限流模型更简单。

1.2 授权码模式（Authorization Code Grant）

授权码模式是 OAuth2 中最完整、最安全的模式。它通过一个临时授权码作为中间凭证，避免访问令牌直接暴露在用户代理环境中。

  1. 资源所有者通过用户代理访问客户端，客户端构造授权请求并重定向到授权服务器。
  2. 资源所有者认证并授权后，授权服务器返回授权码（code）到客户端指定的回调地址。
  3. 客户端使用授权码 + 客户端凭证，通过后端通道向授权服务器请求访问令牌。
  4. 授权服务器验证授权码和客户端身份后，返回访问令牌（access_token）和可选的刷新令牌（refresh_token）。
// 授权码模式令牌请求示例（后端通道）
POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=Au1b2c3d4e5f6g7h8i9j0k
&redirect_uri=https://client.example.com/callback
&client_id=client123
&client_secret=secret456
安全与限流要点： 授权码是一次性凭证，授权服务器必须对 /authorize 端点实施严格的速率限制，防止授权码枚举攻击；同时 /token 端点需防范重放攻击，授权码使用后应立即失效。

1.3 客户端模式（Client Credentials Grant）

客户端模式适用于没有用户参与的机器对机器（M2M）通信。客户端直接使用自己的凭证（client_id + client_secret）向授权服务器请求令牌。

  • 适用场景： 微服务间认证、定时任务、后台数据同步、API 网关内部调用。
  • 限流特征： 无用户维度，限流策略通常基于客户端 ID 或 IP 维度；令牌缓存命中率高，但需注意批量请求导致的突发流量。
  • 安全约束： 客户端凭证必须安全存储，不能暴露在用户代理或日志中；推荐使用 mTLS 或 JWT 客户端断言增强安全性。
// 客户端模式令牌请求示例
POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=service-gateway
&client_secret=svc_secret_789

1.4 资源所有者密码凭证模式（Resource Owner Password Credentials Grant）

此模式允许客户端直接使用资源所有者的用户名和密码换取令牌。由于客户端直接接触用户密码，安全风险较高，OAuth2.1 已将其移除。

压测诊断提示： 密码凭证模式在压测中容易暴露认证服务器的密码验证性能瓶颈。密码哈希计算（如 bcrypt/scrypt）是 CPU 密集型操作，高并发下会显著增加尾延迟。建议在压测时单独监控 /token 端点的 P99 延迟，并与授权码模式对比。 
// 密码凭证模式令牌请求示例
POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=password
&username=user@example.com
&password=my_secret_pass
&client_id=trusted-app
&client_secret=app_secret_012

1.5 隐式模式（Implicit Grant）

隐式模式最初为纯前端应用设计，授权服务器直接返回访问令牌（通常位于 URL 片段中），省略了授权码交换步骤。由于令牌暴露在浏览器历史、Referer 头等位置，安全缺陷明显，已被授权码 + PKCE 全面替代。

  • 安全缺陷： 令牌在 URL 中传递，易被浏览器插件、日志系统、中间代理截获。
  • 限流挑战： 无后端交换环节，限流只能依赖用户代理 IP 或浏览器指纹，精度较低。
  • 现代替代： 授权码模式 + PKCE（Proof Key for Code Exchange）提供同等的简单性，同时具备授权码模式的安全性。

1.6 四种模式综合对比表

对比维度 授权码模式 客户端模式 密码凭证模式 隐式模式
安全等级 高 中（依赖凭证保护） 低 低
令牌刷新支持 是（refresh_token） 通常不提供 是 否
后端交换次数 2 次（授权码 + 令牌） 1 次（令牌） 1 次（令牌） 0 次（直接返回）
限流维度建议 客户端 ID + 用户 ID 客户端 ID 用户 ID + IP IP + 浏览器指纹
OAuth2.1 状态 推荐（+PKCE） 保留 移除 移除

1.7 四种模式交互流程示意图

OAuth2 四种授权模式核心流程对比 授权码模式 ① 用户 → 客户端（请求） ② 客户端 → 授权服务器 ③ 用户认证并授权 ④ 返回授权码（code） ⑤ 后端：code → token ⑥ 返回 access_token ⑦ 使用令牌访问资源 安全：高 | 限流：2 端点 客户端模式 ① 客户端直接请求 ② 携带 client_id + secret ③ 授权服务器验证 ④ 返回 access_token ⑤ 使用令牌调用 API 安全：中 | 限流：1 端点 密码凭证模式 ① 用户提供用户名+密码 ② 客户端直接发送 ③ 授权服务器验证密码 ④ 返回 access_token ⑤ 使用令牌访问资源 安全：低 | 已从 OAuth2.1 移除 隐式模式 ① 用户 → 客户端（请求） ② 客户端 → 授权服务器 ③ 用户认证并授权 ④ 直接返回 token（URL） ⑤ 令牌暴露在浏览器 ⑥ 使用令牌访问资源 安全：低 | 已被 PKCE 替代 限流与压测关键启示 授权码模式需对 /authorize 和 /token 分别限流；客户端模式限流维度最单一；密码凭证模式压测需关注密码哈希性能瓶颈

1.8 模式选择决策树

在实际系统设计中，可依据以下条件快速选择授权模式：

  • 是否有用户参与？
    • 否 → 客户端模式
    • 是 → 继续判断
  • 客户端是否有后端服务？
    • 是 → 授权码模式（推荐 + PKCE）
    • 否（纯前端） → 授权码模式 + PKCE（替代隐式模式）
  • 是否遗留系统且高度信任？
    • 是 → 密码凭证模式（仅限迁移过渡期）
← 上一章 📖 返回目录 下一章 →