维护模式下如何让所有Cookies及Access Tokens失效并强制用户重登？

关于OAuth认证流程的理解验证 #

我维护的系统是多组件架构，共享同一数据库，各组件采用不同技术栈分阶段构建。登录统一调用后端登录服务，上层会话及持久登录基于Cookie、JWT（我统称为“voucher”），推测是OAuth变体。我对流程的理解是：用户登录后，访问服务端点仅验证voucher是否过期，无需每次执行登录逻辑；同时存在刷新机制，voucher过期时可通过有效刷新凭证获取新voucher，无需重新登录。这个理解是否正确？

回答 #

你的理解完全正确。OAuth（包括以JWT作为访问令牌的典型实现）的核心设计就是令牌验证轻量化：用户完成首次登录后，后续请求仅需验证令牌的有效性（签名、过期时间等），无需重复执行账号密码校验的登录逻辑。而刷新令牌机制则是为了在访问令牌（voucher）过期时，通过已授权的刷新凭证（通常是长期有效的令牌或加密凭证）获取新的访问令牌，避免用户频繁重新登录，同时兼顾安全性。

全局失效旧voucher实现维护模式的通用方案 #

当前系统无维护模式，需要在运行时仅允许拥有「Maintenance Access」角色的管理员、测试人员访问，已登录的普通用户需被强制登出，即让所有已颁发的voucher失效。是否存在通用配置修改方式（比如修改JWTVersion属性），无需针对各组件单独处理？

回答 #

存在这类通用方案，核心思路是利用共享数据库的全局统一配置，让所有组件验证voucher时同步校验这个全局规则，具体可参考以下方案：

• 全局令牌版本号方案
  在共享数据库中新增一个全局配置项（比如current_token_version），初始值设为1。后端登录服务颁发voucher（JWT/Cookie）时，将当前的current_token_version值嵌入到voucher中（JWT可放在payload里，Cookie可加密存储该值）。所有组件验证voucher有效性时，除了检查过期时间、签名等常规项，额外校验voucher中的版本号是否与数据库中的current_token_version一致。需要强制所有旧voucher失效时，只需修改数据库中current_token_version的值（比如从1改为2），所有旧voucher因版本不匹配会被判定无效，用户必须重新登录获取新版本的voucher。

• 全局会话失效标记方案
  如果是Cookie-based的会话，可在共享数据库中设置一个全局的maintenance_mode_active标记（布尔值）。组件验证Cookie会话时，除了常规校验，额外查询该标记：若标记为true，则仅允许拥有「Maintenance Access」角色的用户通过，普通用户的会话直接判定失效。结合版本号方案使用效果更佳：开启维护模式时，同时升级令牌版本号，既能拦截新登录的普通用户，又能强制已登录的普通用户登出。

• 注意事项
  确保所有组件的voucher验证逻辑都已同步接入全局配置的校验逻辑（这是一次性改造，后续无需逐个修改组件）。对于JWT这类无状态令牌，版本号是唯一可行的全局失效方案（因为JWT本身无法被主动撤销，只能通过附加的全局规则来判定无效）；而Cookie会话可以结合服务器端的会话存储或全局标记实现失效。

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