Java中如何在JWT到期前将其失效以实现登出功能？

JWT本身的无状态自包含设计，决定了它原生不支持主动失效，要实现这个能力，本质是在原有JWT的无状态校验流程上，增加一层可动态更新的状态校验逻辑，没有能绕开这个核心的“银弹”方案。目前生产环境实际可用的方案主要有三类：

• 维护JWT黑名单（吊销列表）
  实现方式：签发JWT时，给每个令牌分配全局唯一的jti标识字段。用户主动登出时，直接把当前令牌的jti存入带自动过期能力的存储（比如Redis），过期时间就设置为当前JWT本身的剩余有效期，等令牌自然过期后自动清理，不用留存无意义的废弃数据。
  校验流程调整：每次请求到服务端后，先完成JWT的签名合法性校验，解析出令牌对应的jti，查询黑名单中是否存在该标识，存在就直接判定令牌失效，拒绝请求。
  适用场景：对登出立即生效要求高、用户规模中等的系统。优点是可以精准吊销单个设备的单个令牌，实现逻辑简单；缺点是每次请求要多一次存储查询，用户量达到千万级时会带来一定的存储和查询压力。
• 用户级令牌版本号校验
  实现方式：在用户数据表新增token_version字段，每次给用户签发JWT的时候，把这个字段的当前值写进JWT的payload里。当用户主动登出、修改密码、或者触发账号安全风控时，直接把对应用户的token_version做递增操作，旧版本的JWT自然就失效了。
  校验流程调整：解析JWT拿到payload里存储的版本号，和数据库里当前用户的最新版本号对比，数值对不上就直接判定令牌失效。
  适用场景：需要快速吊销某个用户全量令牌的系统。优点是不用单独维护黑名单存储，整体开销比黑名单方案小很多；缺点是控制粒度粗，多设备登录场景下没法单独踢掉某一个设备的会话，会直接把用户所有在线设备的登录状态全部登出。
• 短有效期访问令牌+长期刷新令牌组合
  实现方式：摒弃之前单张长有效期JWT的设计，拆分为两类令牌：一类是有效期极短（一般5-15分钟）的访问令牌，负责日常接口请求的身份校验；另一类是有效期稍长（一般7-30天）的刷新令牌，只用来在访问令牌过期的时候申请新的访问令牌，不直接参与接口鉴权。用户主动登出时，只要把对应用户的刷新令牌标记为失效即可。
  校验逻辑：因为访问令牌本身有效期就很短，就算用户登出后有人窃取到了还没过期的访问令牌，最长可用的窗口也就十几分钟，不会造成长期的安全风险。
  适用场景：用户规模大、对服务端性能要求高的C端系统。优点是鉴权环节几乎不用额外查询状态，对性能影响极小；缺点是存在极短的失效延迟，没法做到登出后立刻让所有相关的访问请求失效。

避坑提醒：别想着靠修改JWT签名密钥实现主动失效，这个操作会直接把所有用户的有效JWT全部置为无效，根本做不到精准吊销单个令牌的效果。

内容的提问来源于stack exchange，提问作者benitta.ruphus