4. 访问令牌与刷新令牌:用途、生命周期管理与安全存储

在 OAuth2.0 授权码模式中,授权服务器在完成用户授权后,会向客户端颁发两种核心凭证:访问令牌(Access Token)和刷新令牌(Refresh Token)。理解两者的职责分工、生命周期控制以及安全存储策略,是后端权限审计的关键环节。

4.1 访问令牌与刷新令牌的用途对比

对比维度 访问令牌(Access Token) 刷新令牌(Refresh Token)
核心用途 作为资源请求的凭证,携带至资源服务器以获取受保护资源 用于在访问令牌过期后,向授权服务器申请新的访问令牌
生命周期 短时效(通常 15 分钟 ~ 1 小时) 长时效(通常数天 ~ 数月,甚至可撤销前长期有效)
作用域 绑定具体的 scope 和资源访问权限 通常继承原始授权范围,也可支持 scope 降级
传输频率 每次 API 请求均需携带 仅在令牌刷新时传输一次
泄露影响 攻击者可短时间访问资源 攻击者可长期持续获取新访问令牌
可撤销性 通常不提供主动撤销(依赖短生命周期) 授权服务器应提供撤销端点,支持主动失效
审计要点:在权限审计中,刷新令牌被视为比访问令牌更敏感的凭证。审计人员应重点检查刷新令牌的颁发策略、存储方式以及撤销机制是否合规。

4.2 生命周期管理策略

生命周期管理直接影响系统的安全性与用户体验。以下是后端架构中必须落实的关键策略:

4.2.1 访问令牌生命周期

  • 短时效原则:访问令牌的过期时间应设置为业务可接受的最短窗口。对于高风险资源,建议 15 分钟;对于常规 API,建议不超过 1 小时。
  • 无状态验证:推荐使用 JWT 格式的访问令牌,资源服务器可本地验证签名与过期时间,无需回查授权服务器。
  • 过期后强制刷新:客户端收到 401 响应后,应使用刷新令牌获取新的访问令牌,而非重试旧令牌。

4.2.2 刷新令牌生命周期

  • 长时效但可撤销:刷新令牌的有效期通常为数天到数月。授权服务器必须提供撤销端点,支持用户主动登出或管理员强制失效。
  • 轮换策略(Rotation):每次使用刷新令牌获取新访问令牌时,授权服务器应同时颁发一个新的刷新令牌,并使旧的刷新令牌失效。这可以限制泄露窗口。
  • 绝对过期时间:即使轮换策略生效,也应设置一个绝对过期时间(如 90 天),防止长期未使用的令牌被滥用。
合规实践:在审计日志中,每次刷新令牌的轮换操作都应记录:旧令牌指纹、新令牌指纹、客户端 ID、刷新时间、IP 地址。这为事后追溯提供了完整的证据链。

4.3 令牌生命周期交互流程

下图展示了访问令牌与刷新令牌在授权码模式中的完整生命周期交互:

访问令牌与刷新令牌生命周期交互图 访问令牌与刷新令牌生命周期交互 客户端 授权服务器 资源服务器 ① 授权码交换 返回 AT + RT ② 携带 AT 请求资源 AT 过期 ③ 返回 401 Unauthorized ④ 携带 RT 请求刷新 ⑤ 返回新 AT + 新 RT 旧 RT 失效(轮换) ⑥ 使用新 AT 继续请求资源 审计关注点: • 步骤④⑤:刷新令牌轮换是否强制实施?旧刷新令牌是否立即失效? • 步骤②⑥:访问令牌是否在每次请求中通过 HTTPS 传输?

4.4 安全存储策略

令牌的安全存储是后端合规的底线要求。以下从客户端侧和服务器侧分别阐述:

4.4.1 客户端侧存储(前端 / 移动端 / 服务端客户端)

客户端类型 推荐存储方式 禁止做法
浏览器 SPA 内存变量 + BFF(Backend for Frontend)代理 localStorage / sessionStorage / Cookie(无安全标记)
原生移动 App 系统安全存储区(iOS Keychain / Android Keystore) SharedPreferences / UserDefaults / 明文文件
服务端客户端 加密数据库或专用密钥管理服务(KMS) 明文配置文件 / 环境变量硬编码

4.4.2 服务器侧存储(授权服务器 / 资源服务器)

  • 访问令牌:推荐无状态 JWT,服务器不持久化存储。签名密钥使用 HS256 或 RS256,密钥定期轮换。
  • 刷新令牌:必须持久化存储,且存储字段应包含:令牌哈希(SHA-256)、客户端 ID、用户 ID、scope、颁发时间、过期时间、是否已撤销。
  • 加密要求:刷新令牌在数据库中以哈希形式存储,原始令牌值仅返回给客户端。授权服务器不应存储明文刷新令牌。
  • 审计日志:所有令牌颁发、刷新、撤销操作均需记录不可篡改的审计日志。
常见审计发现:部分系统将刷新令牌以明文存储在关系数据库中,且未设置过期索引。这违反了 OAuth2.0 安全最佳实践,一旦数据库泄露,攻击者可批量获取长期有效凭证。

4.5 令牌存储架构示意

下图展示了令牌在后端系统中的存储与验证架构:

令牌存储与验证架构图 令牌存储与验证架构 客户端 内存 / 安全存储 HTTPS API 网关 验证 AT 签名 + 过期 RT 刷新请求 授权服务器 RT 哈希存储 资源服务器 本地验证 JWT AT 转发 AT 安全存储要点: • 客户端:AT 存内存,RT 存安全存储区 • 授权服务器:RT 存哈希,不存明文

4.6 审计检查清单

在权限审计中,针对访问令牌与刷新令牌,应逐项检查以下合规点:

  1. 令牌格式:访问令牌是否为 JWT 格式?是否包含 iss、sub、exp、scope 等标准声明?
  2. 过期时间:访问令牌过期时间是否 ≤ 1 小时?刷新令牌是否设置了绝对过期时间?
  3. 刷新轮换:每次刷新是否颁发新刷新令牌?旧刷新令牌是否立即失效?
  4. 存储安全:刷新令牌在数据库中是否以哈希存储?客户端是否避免 localStorage 存储?
  5. 传输安全:所有令牌传输是否强制使用 HTTPS?是否在 URL 参数中传递令牌?
  6. 撤销能力:授权服务器是否提供刷新令牌撤销端点?撤销操作是否记录审计日志?
  7. 日志完整性:令牌颁发、刷新、撤销事件是否包含时间戳、客户端 ID、用户标识、源 IP?
审计结论示例:若系统使用 JWT 访问令牌(15 分钟过期)、刷新令牌轮换策略、RT 哈希存储于数据库、且所有令牌传输均通过 HTTPS,则符合 OAuth2.0 安全基线。若发现刷新令牌未轮换或明文存储,应标记为高风险发现项。