2. OAuth2.0 核心概念回顾：授权码、访问令牌、刷新令牌的生命周期与存储模型
在深入令牌缓存优化之前，必须统一对 OAuth2.0 三种核心令牌的理解。授权码、访问令牌、刷新令牌在生命周期、安全属性与存储模型上存在本质差异，这些差异直接决定了缓存策略的设计边界。
2.1 三种令牌的核心差异
| 令牌类型 | 生命周期 | 安全等级 | 存储位置 | 缓存必要性 |
|---|---|---|---|---|
| 授权码 (Authorization Code) | 极短（通常 30 秒 – 5 分钟） | 最高（一次性使用 + PKCE） | 授权服务器内存 / 临时存储 | 低（一次性，缓存收益极小） |
| 访问令牌 (Access Token) | 中等（通常 15 分钟 – 2 小时） | 中（Bearer 语义，需 TLS 保护） | 资源服务器本地 / 缓存层 | 高（高频验证，缓存热点主要来源） |
| 刷新令牌 (Refresh Token) | 长（数小时 – 数天，甚至持久化） | 高（可轮换、可撤销） | 授权服务器持久化存储 | 中（低频使用，但需高可用） |
关键认知： 访问令牌是缓存优化的主战场。授权码几乎不缓存，刷新令牌的缓存策略以持久化兜底为主。本章后续所有讨论均围绕访问令牌展开。
2.2 授权码：一次性票据的生命周期
授权码是 OAuth2.0 授权码流程的临时凭证，用于交换访问令牌。其生命周期极为短暂，且强制一次性使用。
- 生成时机： 用户授权成功后，授权服务器生成并返回给客户端。
- 使用时机： 客户端携带授权码向令牌端点发起 Token 请求。
- 失效条件： 成功交换令牌后立即失效；超时（通常 60 秒）后自动失效；授权服务器主动撤销。
- 存储模型： 授权服务器内存或高速临时存储（如 Redis 带 TTL），无需持久化。
缓存启示： 授权码的 TTL 极短且一次性，不适合也不需要进行缓存优化。任何对授权码的缓存设计都是过度工程。
2.3 访问令牌：缓存优化的核心对象
访问令牌是客户端访问受保护资源的凭证，也是整个 OAuth2.0 系统中调用频率最高的令牌。其生命周期与存储模型直接决定了缓存架构的复杂度。
2.3.1 生命周期阶段
- 签发： 授权服务器生成令牌，设置
exp（过期时间）和iat（签发时间）。 - 活跃期： 令牌有效期内，资源服务器每次请求都需要验证令牌有效性。
- 过期： 令牌到达
exp时间后，资源服务器拒绝服务，客户端需使用刷新令牌获取新令牌。 - 提前失效（可选）： 授权服务器主动撤销令牌（如用户登出、权限变更），将令牌加入黑名单。
2.3.2 存储模型对比
| 存储模型 | 验证方式 | 缓存友好度 | 典型场景 |
|---|---|---|---|
| 自包含令牌（JWT） | 本地签名验证，无需查库 | 高（无状态，天然抗缓存热点） | 分布式微服务、高并发 API |
| 不透明令牌（Opaque Token） | 每次需查询授权服务器或缓存 | 低（依赖缓存层，易产生热点） | 传统单体应用、安全要求极高的场景 |
| 混合模型 | JWT 携带基础声明 + 缓存存储撤销状态 | 中（需平衡本地验证与缓存查询） | 需要即时撤销能力的高性能系统 |
热点冲击根源： 不透明令牌模型下，每次 API 请求都触发令牌验证查询。当令牌集中过期或大量并发请求涌入同一令牌时，Redis 单节点 QPS 可能瞬间飙升数十倍，形成缓存热点击穿。
2.4 刷新令牌：长生命周期的安全凭证
刷新令牌用于在访问令牌过期后获取新的访问令牌，其生命周期远长于访问令牌，且安全要求更高。
- 生命周期： 通常为数小时到数天，部分场景支持持久化（如“记住我”功能）。
- 安全机制：
- 轮换（Rotation）： 每次使用刷新令牌后，授权服务器签发新的刷新令牌并废弃旧令牌。
- 撤销： 用户主动登出、密码变更、设备吊销时，刷新令牌应立即失效。
- 存储模型： 必须持久化存储（如数据库或 Redis 持久化实例），支持按用户、设备、客户端 ID 快速查询和批量撤销。
缓存策略差异： 刷新令牌的访问频率远低于访问令牌（通常数分钟到数小时一次），因此缓存设计以“高可用 + 持久化兜底”为主，而非“高吞吐”。Redis 热点冲击主要来自访问令牌的验证风暴，而非刷新令牌。
2.5 三种令牌的生命周期与存储模型总览
下图展示了三种令牌在 OAuth2.0 授权码流程中的完整生命周期流转，以及各自对应的存储层级。
2.6 存储模型对缓存优化的直接影响
不同的令牌存储模型决定了缓存策略的选型边界。下表总结了三种模型在缓存优化中的关键差异：
| 维度 | 自包含令牌（JWT） | 不透明令牌 | 混合模型 |
|---|---|---|---|
| 缓存命中率要求 | 低（本地验证为主） | 极高（每次依赖缓存） | 中（本地验证 + 缓存兜底） |
| 热点冲击风险 | 低 | 高 | 中 |
| 撤销实时性 | 差（需黑名单机制） | 好（直接删除缓存） | 好（黑名单缓存 + 本地 TTL） |
| 缓存淘汰策略 | TTL 驱动 | TTL + LRU | TTL + 主动失效 |
| Redis 热点场景 | 黑名单缓存热点 | 令牌验证热点 + 集中过期 | 黑名单 + 部分验证热点 |
实战建议： 如果系统允许，优先采用 JWT 自包含令牌 + 短 TTL 黑名单缓存的混合模型。这能将 80% 的令牌验证压力从 Redis 卸载到本地，大幅降低热点冲击概率。后续章节将详细展开这种架构的缓存优化方案。
2.7 本章小结
- 授权码生命周期极短且一次性，不适合缓存优化。
- 访问令牌是缓存优化的核心对象，不透明令牌模型是 Redis 热点冲击的主要来源。
- 刷新令牌生命周期长但访问频率低，缓存设计以持久化兜底为主。
- 存储模型选择（JWT / 不透明 / 混合）直接决定了缓存策略的复杂度和热点风险等级。