2. OAuth 2.0 核心协议回顾：授权码模式、令牌颁发、刷新令牌、客户端类型与授权类型
OAuth 2.0 是分布式系统中最广泛使用的授权框架，它允许第三方应用在资源所有者（用户）授权的前提下，获取对受保护资源的有限访问权限。本章将系统回顾 OAuth 2.0 的核心协议要素，为后续在分布式事务事件风暴画布中集成安全架构奠定基础。
2.1 授权码模式（Authorization Code Grant）
授权码模式是 OAuth 2.0 中功能最完整、安全性最高的授权类型，适用于有后端服务器的 Web 应用。其核心在于通过一个临时的“授权码”作为中间凭证，避免访问令牌直接暴露在用户代理（浏览器）中。
核心流程（6步交互）：
- 授权请求：客户端将用户导向授权服务器，附带 client_id、redirect_uri、response_type=code 及 scope。
- 用户认证与授权：资源所有者（用户）在授权服务器上登录并确认授权。
- 授权码返回：授权服务器通过重定向将授权码（code）发送到客户端的 redirect_uri。
- 令牌请求：客户端使用授权码、client_id、client_secret 向授权服务器的令牌端点发起 POST 请求。
- 令牌颁发：授权服务器验证授权码和客户端身份后，返回 access_token（通常也包含 refresh_token）。
- 资源访问：客户端使用 access_token 向资源服务器请求受保护资源。
2.2 令牌颁发与刷新令牌
令牌（Token）是 OAuth 2.0 的核心凭证，分为访问令牌（Access Token）和刷新令牌（Refresh Token）。理解它们的生命周期和交互机制，是设计安全分布式事务的基础。
| 令牌类型 | 用途 | 生命周期 | 存储位置 | 安全要求 |
|---|---|---|---|---|
| Access Token | 访问受保护资源 | 短时效（通常 15 分钟 - 1 小时） | 客户端内存或安全存储 | 必须使用 HTTPS 传输；避免在 URL 中传递 |
| Refresh Token | 获取新的 Access Token | 长时效（通常数天到数月） | 服务端安全存储（数据库或缓存） | 必须绑定客户端身份；支持撤销机制 |
刷新令牌的最佳实践：
- 轮换策略（Rotation）：每次使用 Refresh Token 获取新 Access Token 时，同时颁发一个新的 Refresh Token，并使旧的 Refresh Token 失效。这可以防止 Refresh Token 泄露后的长期滥用。
- 撤销机制：当用户主动注销或检测到异常行为时，授权服务器应支持立即撤销 Refresh Token。
- 绑定客户端：Refresh Token 必须与特定的 client_id 和（可选的）client_secret 绑定，防止跨客户端滥用。
2.3 客户端类型与授权类型
OAuth 2.0 根据客户端能否安全保管凭证（client_secret），将客户端分为两类。不同的客户端类型对应不同的授权类型选择。
2.3.1 客户端类型
| 客户端类型 | 定义 | 典型场景 | 安全能力 |
|---|---|---|---|
| 机密客户端 | 能够安全保管 client_secret 的客户端 | 后端 Web 应用、服务端 API | 高：可以执行客户端身份验证 |
| 公开客户端 | 无法安全保管 client_secret 的客户端 | 单页应用（SPA）、移动 App、桌面应用 | 低：不能依赖 client_secret 进行身份验证 |
2.3.2 授权类型对比
OAuth 2.0 定义了四种主要授权类型（Grant Types），每种类型适用于不同的客户端场景和安全需求。
| 授权类型 | 适用客户端 | 是否需要 client_secret | 是否返回 Refresh Token | 安全等级 | 典型场景 |
|---|---|---|---|---|---|
| 授权码模式 | 机密客户端 | 是 | 是 | ★★★★★ | Web 后端应用 |
| 隐式模式（已弃用） | 公开客户端 | 否 | 否 | ★★☆☆☆ | SPA（已被 PKCE 替代） |
| 密码模式 | 机密客户端 | 是 | 是 | ★★★☆☆ | 受信任的第一方应用 |
| 客户端凭证模式 | 机密客户端 | 是 | 否（通常） | ★★★★☆ | 服务间通信（M2M） |
安全警告：隐式模式（Implicit Grant）已在 OAuth 2.1 中正式弃用。对于公开客户端（如 SPA），应使用授权码模式 + PKCE（Proof Key for Code Exchange）扩展，以提供与机密客户端同等级别的安全保障。密码模式（Resource Owner Password Credentials Grant）仅应在高度信任的场景下使用，且不应作为长期授权方案。
2.4 令牌格式与安全传输
OAuth 2.0 规范本身不限定令牌的格式，但实践中最常用的是 JWT（JSON Web Token）和透明令牌（Opaque Token）。
| 令牌格式 | 结构 | 优点 | 缺点 | 典型场景 |
|---|---|---|---|---|
| JWT | Header.Payload.Signature | 自包含、无状态、可验证 | 无法撤销（需配合黑名单） | 分布式系统、微服务 |
| Opaque Token | 随机字符串 | 可撤销、体积小 | 需要服务端查询状态 | 集中式授权服务器 |
安全传输要求：
- HTTPS 强制：所有令牌传输必须使用 TLS 1.2+，防止中间人攻击。
- 避免 URL 传递：Access Token 不应出现在 URL 查询参数中，应使用 Authorization 请求头（Bearer 方案）。
- 最小化暴露：令牌仅应在必要的服务间传递，避免在日志、错误信息或前端代码中泄露。