4. OAuth 2.0 授权框架核心概念：四种授权模式

OAuth 2.0 是当前业界标准的授权框架，它允许第三方应用在用户授权的前提下，安全地访问受保护的资源，而无需暴露用户的长期凭证（如密码）。该框架的核心在于定义了四种不同的授权模式（Grant Types），分别适用于不同的客户端类型与安全场景。作为后端运维与 API 安全专家，理解这四种模式的原理、流程与适用边界，是进行授权测试与接口兼容性校验的基础。

4.1 四种授权模式总览

下表从客户端类型、安全性、典型场景三个维度，对四种模式进行横向对比：

4.2 授权码模式（Authorization Code Grant）

这是最安全、最常用的授权模式。流程中涉及两个关键端点：授权端点（用于获取授权码）和令牌端点（用于换取访问令牌）。客户端必须能够安全地保管 client_secret。

4.3 隐式模式（Implicit Grant）

隐式模式最初为纯前端应用设计，其特点是直接返回访问令牌，跳过了授权码交换步骤。由于令牌直接暴露在 URL 片段中，存在令牌泄露、中间人攻击等严重安全风险。

• 流程简化：用户授权后，授权服务器直接通过重定向 URL 的 # 片段返回 access_token。
• 主要缺陷：无法使用 client_secret 进行身份验证；令牌可能被浏览器历史记录或 Referer 头泄露。
• 替代方案：授权码模式 + PKCE（Proof Key for Code Exchange），后者通过动态生成的 code_verifier 和 code_challenge 实现了无需 client_secret 的安全授权。

4.4 密码模式（Resource Owner Password Credentials Grant）

此模式允许客户端直接使用用户的用户名和密码来换取访问令牌。它违背了 OAuth 2.0 的“不暴露用户凭证”的核心设计目标，因此使用场景受到严格限制。

请求示例（令牌端点）：

POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=password
&username=john_doe
&password=secret_password
&client_id=your_client_id
&client_secret=your_client_secret

4.5 客户端凭证模式（Client Credentials Grant）

此模式专为无用户参与的服务器到服务器通信设计。客户端使用自己的凭证（client_id 和 client_secret）直接向令牌端点请求访问令牌，无需用户授权。

• 典型场景：微服务 A 调用微服务 B 的 API；后台定时任务访问资源服务器；API 网关进行服务间认证。
• 安全要求：客户端必须能够安全存储 client_secret。在生产环境中，建议使用更安全的凭证方式，如 JWT 断言（urn:ietf:params:oauth:client-assertion-type:jwt-bearer）或 mTLS。
• 令牌范围：通常通过 scope 参数限制令牌的访问权限，例如 scope=read_write。

4.6 模式选择决策指南

在实际的授权测试与接口兼容性校验工程中，选择正确的授权模式是第一步。以下决策树可以帮助你快速判断：

1. 是否有用户参与？
   • 否 → 使用 客户端凭证模式。
   • 是 → 进入下一步。
2. 客户端是否能安全保管 client_secret？
   • 是（如后端 Web 应用） → 使用 授权码模式。
   • 否（如纯前端 SPA、移动端） → 使用 授权码模式 + PKCE。
3. 是否属于遗留系统迁移或高度信任的内部应用？
   • 是 → 可考虑 密码模式（需严格评估风险）。
   • 否 → 回到上一步，选择更安全的模式。