短有效期自刷新JWT的风险？为何不采用数据库存储有效JWT？

• 劫持后无限续权：刷新时需将原JWT传给后端，一旦该请求被中间人劫持，攻击者就能用即将过期的原JWT反复请求刷新，获取新的有效JWT，相当于永久持有用户权限——即便后端限制刷新的剩余有效期窗口，只要在窗口内被劫持，攻击者就能续上新token。
• 刷新时机异常导致登录失效：客户端的autoRefresh()依赖本地计时，若遇到网络延迟、客户端休眠唤醒等情况，可能原JWT已过期才发起刷新请求，后端会直接拒绝，用户不得不重新登录，体验极差。
• 无状态优势被削弱：虽然JWT本身是无状态的，但为了支持账号锁定，每次刷新都要查询数据库确认用户状态，这就失去了无状态方案减少数据库查询的核心优势。
• 无法精准失效单个token：如果某个终端的JWT泄露，只能通过锁定整个账号1小时来止损，无法单独废掉这个泄露的token——用户其他正常终端也会被牵连，影响使用。

如果不得不引入refresh token，多数团队不会直接改成数据库存储所有有效JWT的有状态方案，核心原因如下：

• 高并发下的性能瓶颈：每个业务请求都要查数据库校验JWT有效性，高流量场景下数据库会成为性能短板，横向扩展的成本远高于无状态JWT（无状态可直接通过负载均衡分流，无需同步数据库状态）。
• 存储与维护成本高：要存储所有活跃JWT，需定期清理过期token，分布式场景下还要处理缓存一致性问题（比如用Redis做存储），额外增加了系统复杂度和运维成本。
• refresh token方案更轻量化：相比存储大量业务JWT，只存储refresh token的成本低得多——一个用户通常只有几个refresh token（对应不同终端），存储和管理的负担小。同时refresh token可设置较长有效期，搭配短时效业务JWT，既能降低泄露风险，又能减少用户重新登录的频率。
• 迁移与兼容成本低：如果原有系统是基于无状态JWT搭建的，改成完全有状态方案需要重构大量业务接口的校验逻辑；而引入refresh token的改动很小，仅需新增登录和刷新流程的处理，业务接口的JWT校验逻辑基本无需调整。

内容的提问来源于stack exchange，提问作者Darren Zou