Django Rest Framework中JWT刷新后旧令牌未失效问题咨询

你遇到的现象是无状态JWT的固有特性，不属于实现bug，和你当前未做令牌数据库存储的设计直接相关。

• 标准无状态JWT的校验完全不依赖服务端存储：服务端收到JWT后，仅会校验三个维度：签名是否和服务端密钥匹配、是否超出exp字段标注的有效期、令牌携带的权限/用户标识字段是否合法，全程不会查询存储层确认令牌的有效性。只要旧access token没过期、签名没被篡改，不管你后续刷新生成了多少组新令牌，旧token都会一直被认作有效。
• 你之前在OAuth2.0场景观察到的「刷新后旧access token自动失效」，是对应产品的自定义实现，不是协议强制要求：这类实现一般会把所有下发的access、refresh token存在服务端数据库/缓存中，刷新令牌的流程里会主动把旧令牌标记为作废，后续校验时查到作废标记就直接拒绝请求，和JWT本身的规范没有关系。
• 你当前未存储令牌的实现，天然不具备主动作废未过期令牌的能力：服务端根本没有记录过曾经给用户下发过哪些令牌，自然没法在刷新流程里定向让旧access token失效。

如果需要实现刷新后旧令牌失效的安全逻辑，可以根据业务场景选对应方案：

• 缩短access token有效期：这是无状态JWT最通用的实践，把access token过期时间设为5-15分钟，就算旧token泄露或者没被作废，可用窗口极短，风险基本可控，不需要新增任何存储逻辑，性能最好。
• 新增令牌黑名单机制：把刷新流程中替换下来的旧access、refresh token存入Redis这类高速缓存，缓存的过期时间直接设为对应令牌的剩余有效期，校验JWT时先查缓存，命中黑名单就直接拒绝请求。这种方案不需要存储全量有效令牌，只存需要作废的少量令牌，存储压力很低，兼顾性能和安全。
• 采用有状态JWT实现：把所有下发的有效令牌都存入数据库，每次校验JWT都查库确认令牌状态，这种方案对令牌的管控能力最强，但会完全失去JWT无状态的性能优势，仅适合安全等级要求极高的内部系统场景。

内容的提问来源于stack exchange，提问作者HARSH KUMAR CHOUDHARY