Golang 实现 JWT 双 Token 刷新方案

本文深入剖析了在Golang生产环境中实现JWT双Token（Access + Refresh）刷新机制的完整方案，强调这绝非可选优化而是安全底线：通过密钥与解析逻辑完全隔离、设备指纹绑定Redis实现精准吊销、前端共享刷新Promise避免并发冲突、HttpOnly Cookie安全管控及强制校验IssuedAt防重放等关键实践，系统性解决了高并发下令牌复用、状态不一致、无限续期和死循环刷新等真实痛点，为构建健壮、安全、可落地的认证体系提供了详实可靠的技术指南。

双 Token（Access + Refresh）机制不是“可选优化”，而是 JWT 在生产环境必须采用的底线方案。单靠 time.Now().After(claims.ExpiresAt) 做前端刷新判断，必然引发并发重复刷新、令牌复用、状态不一致——这不是边界 case，是每次高并发登录/提交时都会触发的实际问题。

为什么不能共用同一个 JWT 解析函数和密钥

Access Token 和 Refresh Token 必须走完全隔离的解析路径：不同密钥、不同 Claims 结构、不同校验逻辑。共用 ParseToken 函数但不传 isRefresh 参数，会导致以下风险：

• 用 accessSecret 去验 Refresh Token，可能意外通过（若密钥巧合相同），把长期凭证当短期用
• 用 jwt.MapClaims 解析 Refresh Token，却漏掉 jti 或 fingerprint 字段校验，失去防重放能力
• Refresh Token 的 exp 是 7 天，但解析时误套 Access Token 的 15 分钟逻辑，提前拒绝合法刷新

实操上，应定义两个独立函数：ParseAccessToken() 只校验 exp 和 iss；ParseRefreshToken() 必须显式检查 claims.VerifyExpiresAt(now, true) 并返回 user_id 和 jti，且只接受 refreshSecret。

Refresh Token 必须绑定设备指纹并存入 Redis

JWT 标准不支持吊销，所以 Refresh Token 不能纯无状态。不绑定、不落库，等于默认允许无限续期。

• Redis Key 格式建议为 refresh:{user_id}:{fingerprint_hash}，其中 fingerprint_hash 由 sha256(fmt.Sprintf("%s:%s", r.UserAgent(), realIP)) 生成
• 签发时用 SETEX 写入，TTL 设为固定值（如 7 天），而非滑动过期——滑动会延长泄露 Token 的危害窗口
• 刷新接口收到请求后，第一步不是解析 JWT，而是 DEL refresh:{user_id}:{fingerprint_hash}；成功生成新对后再写入新 Key
• 若 DEL 返回 0，说明该设备指纹已被登出或换绑，直接拒绝，不解析 Token

前端拦截器必须共享 Promise，不能各自发请求

多个并发请求同时收到 401，若每个都调 /auth/refresh，服务端就会收到 N 个刷新请求——而 Redis 的 DEL 是原子的，只有一个能成功，其余全失败，前端则陷入“刷新失败 → 清登录态 → 用户正在填的表单丢失”循环。

• 全局维护一个 let refreshPromise: Promise | null = null
• 首次 401 触发 refreshPromise = fetch(...).then(...)，后续所有 401 都 await refreshPromise
• 刷新成功后，用新 accessToken 重放原始请求；失败则 refreshPromise = null 并跳登录页
• 别在拦截器里读 localStorage 取 refreshToken——HttpOnly Cookie 才安全，前端 JS 本就不该接触它

刷新接口必须清旧 Cookie 并拒绝复用旧 jti

如果用 HttpOnly Cookie 存 Refresh Token，刷新成功却不清理旧值，浏览器下次请求仍会自动带上已失效的 Token，导致 401 → 刷新 → 401 死循环。

• 响应中必须调两次 c.SetCookie()：一次清旧（maxAge = -1），一次设新（maxAge = 7*24*3600）
• Redis 中以 jti 为 Key 存储状态，不是 user_id —— 同一用户多设备登录时，必须能单独作废某一台的 Refresh Token
• 刷新成功后，新 Refresh Token 的 jti 必须是服务端新生成的 UUID，禁止客户端传、禁止时间戳拼接
• 别在刷新逻辑里查用户表——sub 和 jti 必须足以完成全部校验，否则引入竞态（如用户刚登出，刷新请求却查到“有效用户”）

最易被忽略的一点：Refresh Token 的 exp 是硬边界，但它的“可用窗口”还受服务端策略约束——比如允许从签发起最多刷新 7 天，这个 7 天不能只靠 JWT 的 exp 控制，而要在解析后比对 claims.IssuedAt 和当前时间，否则攻击者可重放旧 Token 绕过限制。

本篇关于《Golang 实现 JWT 双 Token 刷新方案》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！