1. OAuth2.0 基础回顾：四种授权模式核心流程与适用场景
OAuth2.0 是目前业界标准的授权协议，它允许第三方应用在用户授权的前提下，安全地访问用户存储在资源服务器上的受保护资源，而无需暴露用户的长期凭证（如密码）。协议的核心是定义了四种授权模式，分别对应不同的客户端类型与安全需求。
1.1 授权码模式（Authorization Code Grant）
这是功能最完整、安全性最高的授权模式，适用于有后端服务器的 Web 应用。其核心流程是客户端先获取一个临时授权码，再通过后端服务器与授权服务器交换访问令牌（Access Token），确保令牌不会暴露在用户代理（浏览器）中。
核心流程（6步）：
- 用户访问客户端，客户端将用户重定向至授权服务器，并附带
response_type=code及回调 URI。 - 用户登录并授权。
- 授权服务器将授权码通过重定向发送至客户端的回调 URI。
- 客户端后端使用授权码，向授权服务器请求访问令牌（需提供
client_secret验证）。 - 授权服务器验证授权码及客户端身份，返回访问令牌（及可选的刷新令牌）。
- 客户端使用访问令牌请求资源服务器上的受保护资源。
1.2 隐式模式（Implicit Grant）
隐式模式专为纯前端应用（如单页应用 SPA）设计，授权服务器直接返回访问令牌，跳过了授权码交换步骤。由于令牌直接暴露在 URL 片段中，安全性较低，已不推荐使用，建议改用授权码模式 + PKCE 扩展。
| 特性 | 授权码模式 | 隐式模式 |
|---|---|---|
| 令牌传输 | 后端服务器间传输，不暴露给浏览器 | 直接通过 URL 片段返回给浏览器 |
| 客户端类型 | 有后端的 Web 应用 | 纯前端 SPA |
| 安全性 | 高（支持客户端认证） | 低（令牌易泄露） |
| 刷新令牌 | 支持 | 不支持 |
| 当前推荐度 | 强烈推荐 | 已弃用，改用 PKCE |
1.3 密码模式（Resource Owner Password Credentials Grant）
用户直接向客户端提供用户名和密码，客户端使用这些凭证向授权服务器换取访问令牌。此模式要求客户端高度可信（如官方第一方应用），且用户密码会暴露给客户端，存在较大安全风险。
安全警告：密码模式仅适用于客户端与资源服务器属于同一组织或高度信任的场景。在第三方应用场景中，应避免使用此模式，因为用户需要将密码直接交给客户端，违背了“最小权限”原则。
1.4 客户端凭证模式（Client Credentials Grant）
此模式不涉及用户授权，客户端直接使用自己的凭证（client_id + client_secret）向授权服务器请求访问令牌。适用于服务器到服务器的通信场景，如微服务间调用、后台批处理任务等。
1.5 四种模式对比总结
| 授权模式 | 核心流程 | 典型客户端 | 安全性 | 是否支持刷新令牌 |
|---|---|---|---|---|
| 授权码模式 | 用户授权 → 授权码 → 后端换令牌 | 有后端的 Web 应用 | 高 | 是 |
| 隐式模式 | 用户授权 → 直接返回令牌 | 纯前端 SPA | 低（已弃用） | 否 |
| 密码模式 | 用户提供密码 → 客户端换令牌 | 官方第一方应用 | 中（需高度信任） | 是 |
| 客户端凭证模式 | 客户端凭证 → 直接换令牌 | 微服务、后台任务 | 高（无用户参与） | 是 |
选型建议：在大多数 Web 应用场景中，优先选择授权码模式 + PKCE。密码模式应仅用于高度信任的内部系统。客户端凭证模式是微服务架构中服务间鉴权的标准方案。