2. OAuth2.0 核心概念回顾：Access Token、Refresh Token、Client Credentials Grant、Authorization Code Grant
在深入异步任务编排与缓存策略之前，必须重新夯实 OAuth2.0 的四个核心概念。这些概念是令牌生命周期管理的基石，直接决定了缓存策略的选型边界。
2.1 令牌双生子：Access Token 与 Refresh Token
OAuth2.0 将授权与资源访问分离，通过两种令牌实现：
| 属性 | Access Token（访问令牌） | Refresh Token（刷新令牌） |
|---|---|---|
| 用途 | 携带在请求头中访问受保护资源 | 在 Access Token 过期后获取新的 Access Token |
| 有效期 | 短（通常 15 分钟 ~ 1 小时） | 长（通常 7 天 ~ 30 天，可轮换） |
| 存储位置 | 客户端内存 / 缓存（高频读取） | 安全存储 / 缓存（低频读取） |
| 泄露风险 | 高（需短生命周期 + 作用域限制） | 极高（需绑定客户端 + 一次性使用） |
| 缓存策略关注点 | 高并发读、过期驱逐、提前刷新 | 安全轮换、并发保护、持久化 |
关键认知：Access Token 是“通行证”，Refresh Token 是“补办凭证”。缓存设计必须区分两者的读写频率和安全等级，不能混用同一套过期策略。
2.2 两种核心授权流程
OAuth2.0 定义了多种授权流程，其中 Authorization Code Grant 和 Client Credentials Grant 是异步任务编排中最常遇到的两种模式。
2.2.1 Authorization Code Grant（授权码模式）
适用于有前端的 Web 应用或移动应用，代表“用户代理”参与授权。流程包含用户、客户端、授权服务器、资源服务器四方交互。
- 用户访问客户端，客户端将用户重定向到授权服务器。
- 用户认证并授权，授权服务器返回授权码（Authorization Code）到客户端回调地址。
- 客户端用授权码换取令牌：携带授权码 + Client Secret 向授权服务器请求 Access Token 和 Refresh Token。
- 客户端使用 Access Token 访问资源服务器。
缓存设计影响：此模式涉及用户身份，令牌必须与用户会话绑定。缓存 Key 通常为
user_id:token_type，且需支持多租户隔离。Refresh Token 的轮换操作必须加分布式锁，防止并发刷新导致令牌失效。
2.2.2 Client Credentials Grant（客户端凭证模式）
适用于服务间通信、后台任务、定时脚本等无用户参与的场景。客户端直接使用自己的身份（Client ID + Client Secret）获取令牌。
- 无用户概念：令牌代表客户端自身，而非某个用户。
- 通常不颁发 Refresh Token：因为 Client Secret 可以随时重新获取令牌，Refresh Token 反而增加复杂度。
- 缓存命中率高：同一客户端的所有请求共享同一个 Access Token，非常适合集中缓存。
| 对比维度 | Authorization Code Grant | Client Credentials Grant |
|---|---|---|
| 参与方 | 用户、客户端、授权服务器、资源服务器 | 客户端、授权服务器、资源服务器 |
| 令牌粒度 | 每个用户独立令牌 | 每个客户端共享令牌 |
| Refresh Token | 通常颁发，需安全存储 | 通常不颁发 |
| 缓存 Key 设计 | user_id:client_id |
client_id |
| 并发刷新风险 | 高（多用户同时刷新） | 低（单客户端全局刷新） |
2.3 令牌缓存的核心挑战
基于上述概念，异步任务编排中的令牌缓存面临三个核心挑战：
- 并发刷新风暴：多个异步任务同时发现 Access Token 过期，同时发起刷新请求，导致授权服务器压力激增。
- 令牌状态不一致：Refresh Token 被轮换后，旧令牌失效。若缓存未及时更新，后续任务使用旧令牌刷新会失败。
- 过期窗口内的空窗期：令牌在缓存中刚过期，但新令牌尚未获取成功，此时所有请求都会失败。
常见误区：不要将 Access Token 的过期时间设置为缓存 TTL 的精确值。例如令牌有效期 15 分钟，缓存 TTL 也设为 15 分钟，会导致大量请求在令牌实际过期前因缓存驱逐而失败。正确的做法是设置缓存 TTL 为令牌有效期的 70%~80%，并配合异步预刷新机制。