密钥轮转期间保证旧 JWT Token 有效的最推荐方案是采用双密钥验证机制或引入 KID（Key ID）字段标识密钥版本。该方案适用于需要零停机更新的生产环境，风险边界在于密钥管理复杂度增加及旧密钥清理不及时可能导致的安全隐患。
先说结论：通过服务端验证逻辑兼容新旧密钥，并设置合理的宽限期，可实现用户无感知的密钥轮换。
- 先判断：确认当前签名算法是 HMAC 还是 RSA，RSA 非对称签名更适合安全轮换。
- 优先做：配置双密钥共存，验证逻辑需遍历密钥列表或根据 KID 路由到对应密钥。
- 再验证：使用旧密钥签发的 Token 请求新接口，确认返回 200 而非 401 错误。
快速处理思路
若无法立即修改架构，可通过环境变量加载多个密钥，并在验证函数中循环尝试。以下为核心验证逻辑的伪代码示例：
def verify_jwt_token(token):
for secret_key in [NEW_KEY, OLD_KEY]:
try:
payload = jwt.decode(token, secret_key, algorithms=['HS256'])
return payload
except JWTError:
continue
raise Exception("无效 Token")对于支持 KID 的场景，需在 Token Header 中写入密钥 ID，服务端根据 KID 从密钥仓库查找对应公钥进行验签。
为什么会这样
JWT 签名依赖密钥生成，密钥变更会导致旧签名无法匹配。JWT 由 Header、Payload 和 Signature 组成，Signature 是使用密钥对前两部分计算得出的哈希值。若服务端仅持有新密钥，无法复现旧密钥生成的签名，导致验证失败。双密钥机制本质是让服务端在验证阶段保留旧密钥的计算能力，直到旧 Token 自然过期。
分步处理
1. 准备新密钥并配置环境变量
生成强随机新密钥，将其添加至配置中心或环境变量列表，确保所有服务实例可读取。旧密钥暂时保留，标记为“待淘汰”。
2. 更新验证逻辑支持多密钥
修改认证中间件，使其支持密钥列表遍历或基于 KID 的动态加载。若使用 HMAC 算法，需确保新旧密钥同时存在于验证白名单中。
3. 设置宽限期并监控旧密钥使用
设定旧密钥的有效期（例如 72 小时），在此期间记录使用旧密钥签发的 Token 访问日志。监控旧密钥的调用频率，确认流量是否已迁移至新密钥。
4. 清理旧密钥配置
宽限期结束后，确认无活跃旧 Token，从配置中移除旧密钥。若使用 KID 机制，从 JWKS 端点移除旧公钥。
怎么验证是否生效
1. 接口测试：使用轮转前生成的旧 Token 请求受保护接口，预期状态码为 200 而非 401。
2. 日志检查：查看服务端认证日志，确认旧密钥 ID 或被标记为旧的密钥成功通过了验签流程。
3. 新 Token 验证：使用新密钥生成的新 Token 请求接口，确认新流程正常工作。
常见坑
1. KID 字段未校验白名单：若仅依赖 Header 中的 KID 加载密钥而未校验合法性，攻击者可能构造恶意 KID 路径遍历文件。
2. 算法混淆风险：部分库在未指定算法列表时可能默认接受多种算法，需强制指定 algorithms 参数防止算法降级攻击。
3. 分布式时钟漂移：若 Token 依赖 exp 字段，服务器间 NTP 时间偏差超过 5 秒可能导致同一 Token 在不同节点验证结果不一致。
4. 旧密钥清理滞后：宽限期结束后未及时移除旧密钥，会增加密钥泄露后的攻击窗口。
常见问题
密钥泄露后必须立即强制所有用户下线吗？
不一定，若采用双密钥轮换且旧密钥未泄露，可仅停用泄露密钥并签发新 Token。但若签名密钥本身泄露，攻击者可伪造任意 Token，建议立即轮换密钥并设置短宽限期。
HMAC 和 RSA 哪种更适合密钥轮换？
RSA 非对称签名更适合，因为验证只需公钥，私钥可离线保管。HMAC 对称密钥需所有验证服务持有相同密钥，轮换同步难度更高。
宽限期设置多久比较合适？
通常参考 Access Token 的最长有效期，例如 72 小时或 7 天。具体时长需结合业务容忍度，时间越短安全风险越低，但用户掉线概率越高。
参考来源
- jwttoken 过期了，我修改看 jwt_key 该怎么办
- FastAPI JWT 密钥轮换：无缝过渡的完整指南
- JWT 签名密钥泄露如何安全轮换？_编程语言-CSDN 问
- SpringBoot 实现 JWT 动态密钥轮换
- 终极指南:Java-JWT 密钥安全存储与轮换的 7 个最佳实践