1. OAuth2.0 基础回顾：四种授权模式的核心流程与适用场景
OAuth2.0 是业界标准的授权框架，允许第三方应用在用户授权的前提下，有限度地访问资源拥有者在资源服务器上托管的受保护资源。整个协议的核心是 授权码（Authorization Code）、隐式（Implicit）、密码（Resource Owner Password Credentials） 和 客户端凭证（Client Credentials） 四种授权模式。理解它们的流程差异与适用边界，是后续设计熔断降级策略与性能调优的基础。
1.1 四种授权模式核心流程对比
| 授权模式 | 核心参与者 | 令牌传输方式 | 刷新令牌支持 | 安全等级 |
|---|---|---|---|---|
| 授权码 | 用户、客户端、授权服务器、资源服务器 | 后端通道（code → token） | ✅ 支持 | 最高（推荐） |
| 隐式 | 用户、客户端（浏览器）、授权服务器 | 前端通道（fragment） | ❌ 不支持 | 较低（已逐步淘汰） |
| 密码 | 用户、客户端、授权服务器 | 直接凭据交换 | ✅ 支持 | 中等（仅限信任客户端） |
| 客户端凭证 | 客户端、授权服务器 | 直接凭据交换 | ✅ 支持 | 高（无用户参与） |
架构师提示： 在微服务与 API 网关场景中，授权码模式是首选；隐式模式因安全缺陷（令牌暴露在浏览器历史/Referer 头）已被 OAuth2.1 正式移除。密码模式仅适用于第一方应用（如官方移动 App），客户端凭证模式则专用于服务间通信。
1.2 授权码模式（Authorization Code Grant）
这是功能最完整、安全性最高的模式。客户端不直接接触用户凭证，而是通过授权服务器颁发的临时授权码（code）换取访问令牌（access token）。整个流程包含两次独立的 HTTP 重定向和一次后端通道的令牌请求。
适用场景：
- 第三方 Web 应用（如使用 GitHub 登录的 SaaS 平台）
- 原生移动 App（配合 PKCE 增强安全）
- 单页应用（SPA，配合 PKCE + 后端代理）
1.3 隐式模式（Implicit Grant）
隐式模式专为纯浏览器端应用设计，授权服务器直接通过 URL 片段（fragment）返回 access_token，跳过了授权码交换步骤。由于令牌直接暴露在浏览器环境中，安全风险较高。
- 流程简化： 用户授权 → 授权服务器直接返回 access_token（#token）→ 客户端从 fragment 提取令牌。
- 安全缺陷： 令牌出现在浏览器历史、Referer 头、中间人攻击面大；不支持 refresh_token。
- 现状： OAuth2.1 已移除该模式，建议迁移至授权码 + PKCE。
架构师避坑： 如果遗留系统仍使用隐式模式，务必在网关层增加令牌绑定（Token Binding）或短期令牌 + 定期重新授权机制，避免令牌长期泄露。
1.4 密码模式（Resource Owner Password Credentials Grant）
用户直接将用户名/密码交给客户端，客户端用这些凭据向授权服务器换取令牌。这种模式违背了 OAuth 的“授权委托”初衷，仅在绝对信任的场景下使用。
适用场景：
- 官方第一方应用（如官方客户端登录）
- 迁移遗留系统时的临时过渡方案
- 高信任内部系统（如企业内部门户）
1.5 客户端凭证模式（Client Credentials Grant）
该模式不涉及用户，客户端直接使用自身凭证（client_id + client_secret）向授权服务器申请令牌。常用于服务间通信、后台任务或机器对机器（M2M）场景。
- 流程极简： 客户端 → 授权服务器（grant_type=client_credentials）→ 返回 access_token。
- 无用户上下文： 令牌代表客户端本身，而非某个用户。
- 令牌缓存友好： 同一客户端可复用令牌，减少授权服务器压力。
性能调优切入点： 客户端凭证模式是四种模式中吞吐量最高的，但也是最容易被忽视的熔断盲区。当授权服务器令牌端点出现延迟抖动时，大量 M2M 客户端会同时重试，形成“重试风暴”。建议在客户端 SDK 层实现指数退避 + 本地令牌缓存（TTL 缩短 10% 作为安全余量）。
1.6 四种模式选型决策矩阵
| 决策维度 | 授权码 | 隐式 | 密码 | 客户端凭证 |
|---|---|---|---|---|
| 用户交互 | ✅ 需要 | ✅ 需要 | ✅ 需要 | ❌ 不需要 |
| 客户端类型 | Web / 原生 / SPA | SPA（已淘汰） | 第一方 App | 后端服务 / 微服务 |
| 令牌刷新 | ✅ 支持 | ❌ 不支持 | ✅ 支持 | ✅ 支持 |
| 熔断优先级 | 高（用户感知强） | 中 | 高（凭据验证依赖） | 高（重试风暴风险） |
| 性能瓶颈点 | 授权端点 + 令牌端点 | 授权端点 | 身份源 + 令牌端点 | 令牌端点 |
架构师决策提醒： 在微服务网关层统一实施熔断降级时，必须按 授权模式 + 客户端来源 拆分熔断维度。例如：授权码模式的 /authorize 端点按 client_id 分组熔断，客户端凭证模式的 /token 端点按客户端 IP 或服务名分组熔断。混用单一熔断器会导致“误伤”——一个高流量客户端的故障可能拖垮所有其他客户端的授权请求。