这是一个关于 OAuth 2.0 / JWT 安全架构的经典问题。答案是取决于你的安全策略但推荐每次刷新都重新生成 Refresh Token。两种策略对比策略 优点 缺点 适用场景每次重新生成推荐 安全性高可检测 Token 复用 需要维护更多状态 大多数 Web/App 应用固定不变 实现简单用户体验好 泄露后无法撤销无法检测复用 低安全要求场景为什么推荐每次刷新都重新生成1. 安全检测Token 复用检测Token Rotation Reuse Detection这是核心原因。如果攻击者窃取了 Refresh Token而合法用户也在使用- 重新生成策略服务器发现旧 Refresh Token 被再次使用时可以立即吊销整个 Token 家族所有派生的 Access/Refresh Token因为旧 Token 应该已被替换- 固定策略攻击者和合法用户都能无限刷新你无法区分2. 限制泄露窗口如果 Refresh Token 泄露- 重新生成最多泄露 1 个 Access Token 的有效期- 固定攻击者可以一直刷新直到用户主动退出或 Token 过期3. 符合 OAuth 2.0 最佳实践[RFC 6819 (OAuth 2.0 Threat Model)](https://datatracker.ietf.org/doc/html/rfc6819) 和 [OAuth 2.1 草案](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-10) 都明确推荐 Refresh Token Rotation。实际实现方案方案 A滑动窗口Sliding Window— 最常用用户登录↓生成 Refresh Token A有效期 30 天↓用 A 刷新 → 生成新 Access Token 新 Refresh Token B有效期从当前重新计算 30 天↓旧 A 失效记录 A 的 family_id↓用 B 刷新 → 生成新 Access Token 新 Refresh Token C关键点- 新 Refresh Token 有效期重新计算不是继承旧 Token 的剩余时间- 旧 Refresh Token 立即失效或给一个极短的宽限期如 5 秒防止并发请求失败- 所有 Token 属于同一个 family家族方便批量吊销方案 B固定 Refresh Token但缩短有效期如果业务要求简单- Refresh Token 有效期设为 7 天而非 30 天- 每次刷新时不重新生成但更新最后活跃时间- 超过 7 天不活跃则强制重新登录方案 CRefresh Token 家族Family 宽限期处理并发刷新的优雅方案// 伪代码func refresh(refreshToken string) {token, err : db.GetRefreshToken(refreshToken)if err ! nil {return 401}// 检查是否被吊销if token.Revoked {// 检测到复用吊销整个家族db.RevokeTokenFamily(token.FamilyID)// 通知用户可选发送邮件/推送return 401, Token reuse detected, please re-login}// 生成新 Token 对newAccess, newRefresh : generateTokens()// 旧 Token 标记为已使用宽限期 5 秒db.MarkAsUsed(token.ID, gracePeriod5*time.Second)// 新 Refresh Token 继承 familydb.SaveRefreshToken(newRefresh, familyIDtoken.FamilyID)return newAccess, newRefresh}常见误区误区 纠正重新生成 Refresh Token 太频繁数据库压力大 Refresh Token 存储本身就需要持久化多一条记录开销极小用户同时打开多个标签页刷新会冲突 用 Family 宽限期5-10 秒解决第一个请求生成新 Token后续请求在宽限期内仍可用旧 Token移动端不需要这么严格 移动端反而更需要因为设备更容易丢失/被盗总结场景 建议金融/支付类应用 必须每次重新生成 复用检测普通 Web/App 推荐每次重新生成Family 5 秒宽限期内部工具/低安全要求 可以固定但缩短有效期到 7 天以内核心原则Refresh Token 是长期凭证它的安全性比 Access Token 更重要。每次刷新时重新生成 Refresh Token是成本最低、收益最高的安全加固措施。
