4. JWT令牌的生命周期管理：Access Token与Refresh Token的职责划分、令牌过期策略设计、令牌撤销机制

在微服务与分布式架构中，JWT（JSON Web Token）作为无状态认证的核心载体，其生命周期管理直接决定了系统的安全水位与用户体验。本章围绕令牌的职责划分、过期策略与撤销机制展开，帮助架构师在服务边界划分时做出正确的令牌治理决策。

4.1 Access Token与Refresh Token的职责划分

双令牌模型是现代API安全的事实标准。Access Token负责短期资源访问，Refresh Token负责长期会话续期。两者在生命周期、存储位置、传输方式上存在本质差异。

4.2 令牌过期策略设计

过期策略是安全性与易用性之间的平衡杠杆。过短则频繁刷新影响体验，过长则泄露风险窗口增大。以下是三种主流策略及其适用场景。

4.2.1 固定过期策略

• Access Token：固定15分钟，到期后必须使用Refresh Token续期。
• Refresh Token：固定7天，到期后用户需重新登录。
• 适用场景：企业内部系统、低风险环境。

4.2.2 滑动过期策略

• Access Token：固定15分钟，不变。
• Refresh Token：每次刷新时重置过期时间（如从当前时间起延长7天）。
• 适用场景：移动端应用、需要长期在线的用户。
• 风险：用户长期不退出，需配合最大绝对过期时间（如30天强制重新登录）。

4.2.3 分级过期策略

• Access Token：根据操作敏感度动态调整（读操作30分钟，写操作10分钟，敏感操作5分钟）。
• Refresh Token：根据用户信任等级（新设备1天，常用设备7天，受信任设备30天）。
• 适用场景：金融、医疗等高安全领域。

4.3 令牌撤销机制

JWT的无状态特性使得撤销成为架构难点。令牌一旦签发，在过期前无法通过签名验证使其失效。以下是三种主流的撤销方案。

4.3.1 黑名单机制（Blacklist）

• 原理：将需要撤销的令牌的jti（JWT ID）存入高速缓存（Redis），每次验证时检查是否在黑名单中。
• 优点：实现简单，撤销即时生效。
• 缺点：引入状态依赖，增加验证延迟；黑名单随撤销量增长需定期清理。
• 适用：用户主动登出、管理员强制下线。

4.3.2 版本号机制（Version-based）

• 原理：在用户表中维护一个token_version字段，JWT声明中包含该版本号。版本号变更（如密码修改）使所有旧令牌失效。
• 优点：批量撤销高效，无需额外存储。
• 缺点：无法精确撤销单个令牌；每次验证需查询数据库获取版本号。
• 适用：密码重置、权限变更等全局事件。

4.3.3 短生命周期 + 刷新限制

• 原理：Access Token有效期极短（5分钟），Refresh Token绑定设备指纹或IP，刷新时检查是否异常。
• 优点：无需显式撤销，泄露窗口极小。
• 缺点：刷新频率高，增加认证服务器负载。
• 适用：高安全场景，配合滑动过期使用。

4.4 令牌刷新流程与安全约束

刷新流程是双令牌模型的核心交互环节。设计不当会导致安全漏洞或性能瓶颈。以下是标准刷新流程及关键安全约束。

4.4.1 标准刷新流程

1. 客户端检测到Access Token过期（HTTP 401 或本地过期判断）。
2. 客户端携带Refresh Token向认证服务器发送刷新请求（POST /auth/refresh）。
3. 认证服务器验证Refresh Token的签名、有效期、撤销状态。
4. 验证通过后，颁发新的Access Token（可选同时颁发新的Refresh Token）。
5. 客户端使用新Access Token重新请求资源。

4.4.2 安全约束清单

4.5 令牌生命周期全景图

将上述所有概念整合为一个完整的生命周期视图，帮助架构师在设计阶段建立全局认知。

4.6 架构决策清单

在服务边界划分中，令牌生命周期管理直接影响认证服务的部署位置与数据一致性要求。以下是关键决策点：

• 认证服务独立部署：令牌颁发与刷新应集中在认证服务，避免多个服务各自维护令牌状态导致不一致。
• 黑名单共享：如果采用黑名单机制，所有服务必须共享同一Redis集群，确保撤销即时生效。
• 版本号同步：版本号机制要求用户服务与认证服务之间保持数据一致性，建议使用事件驱动或分布式缓存。
• 刷新端点保护：刷新端点应实施限流、设备指纹验证、异常检测，防止令牌滥用。
• 日志与审计：所有令牌颁发、刷新、撤销操作必须记录审计日志，便于事后追溯。