如何在Go微服务中设计基于JWT无感刷新的双Token认证机制

先说一个核心判断：双Token机制在Go微服务的JWT体系里，并不是一个“可选项”，它几乎是强制性的前置条件。如果还在用单Token续期，高并发场景下迟早要撞上那三个经典故障——并发刷新导致Token混乱、旧的Refresh Token被重复利用、以及表单提交过程中因Token过期而中断。这些不是理论推演，生产环境里反复出现过。

换句话说，双Token结构不是锦上添花，而是JWT落地的底线要求。单Token续期在高并发下必然会引发并发刷新冲突、旧Refresh Token复用、以及表单提交中断这三类真实故障。

ParseAccessToken 和 ParseRefreshToken 必须完全隔离

很多实现会犯一个看似不起眼的错误：两个Token共用同一个解析函数，只是换了密钥。结果呢？某个场景下，Refresh Token被当成了Access Token解析，竟然通过了token.Valid == true的校验，但后续读取claims["scope"]时空指针或类型错乱——这就是权限越界的典型表现，admin接口可能因此被一个本该过期的Token放行。

正确的做法是：

• ParseAccessToken() 只接受 accessSecret，校验 exp 和 iss，返回 user_id 和基础权限字段（如 role），不读取 jti 或 fingerprint。
• ParseRefreshToken() 必须显式传入 refreshSecret，且只接受自定义结构体（含 jti、fingerprint 字段），然后用 claims.VerifyExpiresAt(now, true) 严格比对过期时间。
• 绝对禁用 jwt.MapClaims 来解析 Refresh Token。这东西绕过了字段类型校验，jti 缺失或者被传成了 int 类型，防重放逻辑瞬间失效——不是可能失效，是必然失效。

Refresh Token 必须绑定设备指纹并原子消费

JWT本身是没有吊销能力的。如果不把Refresh Token落进Redis，那就等于允许无限续期。你也许觉得泄露一个Refresh Token不至于那么严重，但实话讲，这已经是生产环境里反复复现过的漏洞了。

关键设计点有几个：

• Redis Key 格式固定为 refresh:{user_id}:{fingerprint_hash}，其中 fingerprint_hash 是 sha256(fmt.Sprintf("%s:%s", r.UserAgent(), realIP))，IP不可省略——光靠UserAgent不够，容易伪造。
• 签发时用 SETEX 写入，TTL 设成硬性值（比如 7 * 24 * time.Hour）。别用 EXPIRE 做滑动更新，否则攻击者可以不断延长有效期，等于白设。
• 刷新接口的第一行就执行 DEL refresh:{user_id}:{fingerprint_hash}。如果返回 0，说明这个设备已经被登出或者换绑了，直接拒绝，不再走后续解析JWT的流程。
• 成功生成新Token对之后，才写入新的Key。查用户表？不需要。读 request.Body 里的 user_id？也不行。唯一可信的来源就是解析出的 claims["user_id"] 和 claims["jti"]。

HTTP Header 必须分离 Authorization 和 X-Refresh-Token

把Refresh Token也塞进 Authorization: Bearer xxx 里，后果就是中间件可能误判。尤其当Access Token已经过期，但Refresh Token还有效时，鉴权层可能直接拒绝请求，而不是转发到刷新路由——这等于把刷新逻辑提前堵死了。

规范做法很简单：

• Access Token 走 Authorization: Bearer 。
• Refresh Token 单独走 X-Refresh-Token: ，避免中间件混淆。
• 别把Refresh Token顺手塞进Cookie让它自动发送。前端必须显式放在请求体或者header里携带，防止在CSRF场景下被自动提交。
• 刷新接口返回的新 refreshToken 必须立即生效。很多实现只更新了新值，却忘了删旧Key，导致一次泄露就可以无限续期——Redis里旧记录还在，攻击者拿着旧Token照样能用。

前端拦截器必须共享 Promise，不能各自重试

高并发场景下，多个请求同时拿到 401，如果每个请求都独立去调 /auth/refresh，服务端Redis的 DEL 原子性会让结果变成：只有一个成功，其余全部失败。前端就会陷入“刷新失败 → 清登录态 → 表单丢失”的死循环。

解法其实不复杂：

• 维护一个全局 refreshPromise 变量，第一次收到 401 时触发刷新，并把Promise缓存起来。
• 后续同一批 401 请求，全部 await refreshPromise，而不是各自发新请求。
• 刷新成功后，用新Token重放原始请求；失败则清空登录态。
• 长连接场景（WebSocket/gRPC），服务端需要在Token过期前主动预推送新Token（比如 exp 前5分钟），不能等过期了再响应。因为握手后无法再发HTTP头，靠客户端轮询又破坏连接语义。

整个刷新链路中最容易被忽视的，其实是状态一致性。Redis Key删除、新Token签发、旧Token失效这三步，必须构成一个原子操作边界。任何一步失败都应该回滚，或者明确拒掉，而不是“尽力而为”。经验表明，生产环境里90%的Token泄露问题，根源不在加密技术强不强，而在于状态管理松散——该删除的没删，该校验的漏了，该原子操作的散了。