当JWT验证为无状态时，OIDC /revoke如何处理JWT访问令牌？

无状态JWT的本地验证（签名、过期时间、声明校验）本身无法感知令牌被提前撤销——因为这种机制完全依赖令牌自身携带的信息，没有中心化的状态同步渠道。要解决和/revoke撤销端点的协同问题，你需要额外引入以下几种常用方案：

1. 短生命周期AccessToken + 刷新令牌 #

把AccessToken的有效期设得极短（比如5-15分钟），同时搭配RefreshToken使用。当调用/revoke撤销时，OIDC提供商同时失效对应的RefreshToken：

• 未过期的AccessToken在失效窗口内仍能通过本地验证，但窗口很短，风险可控；
• 用户后续需要续期AccessToken时，必须用RefreshToken请求新令牌，此时OIDC提供商会拒绝已被撤销的RefreshToken，从而阻断后续的令牌使用。
  这是目前最主流的折中方案，兼顾无状态特性和撤销需求。

2. 维护令牌黑名单 #

搭建一个中心化的黑名单存储（比如Redis），将被撤销的未过期AccessToken存入其中，并设置与令牌过期时间一致的TTL（自动过期清理）。
验证流程需要在本地校验的基础上，额外增加一步：查询黑名单，确认当前令牌未被列入。
这种方案打破了纯无状态，但实现简单，适合对撤销及时性有要求、且能接受轻微性能损耗的场景。

3. 调用令牌 introspection 端点 #

按照RFC7662规范，调用OIDC提供商的令牌 introspection 端点，每次验证时直接查询令牌的实时有效性（包括是否被撤销）。
这种方案完全依赖OIDC提供商的状态，准确性最高，但会让每次请求都增加一次第三方服务调用，失去了无状态JWT的性能优势，仅适合安全性优先级远高于性能的场景。

总结来说，纯无状态JWT验证本身不支持提前撤销的感知，必须结合上述额外机制来实现和/revoke端点的协同，具体方案需根据业务的安全、性能、复杂度需求权衡选择。

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