登出时如何处理Access Token与Refresh Token？

针对你遇到的问题，核心结论是：必须将Refresh Token也加入Redis黑名单——仅前端移除Cookie无法彻底失效Token，因为签名有效的Refresh Token仍能被用来获取新的Access Token。以下是具体的处理方案和优化建议：

1. 强制将Refresh Token加入黑名单 #

• 和Access Token的处理逻辑一致，用户登出时，把当前有效的Refresh Token存入Redis黑名单，并设置过期时间与该Refresh Token本身的有效期（30天）保持一致。Redis会自动清理过期的黑名单条目，无需手动维护。
• 每次处理Refresh Token的刷新请求时，先检查该Token是否存在于黑名单中：若存在，直接返回“已登出”的错误，拒绝生成新的Access Token；若不存在，再验证签名和有效期，正常处理刷新逻辑。

2. 可选优化：Refresh Token一次性使用机制 #

为进一步提升安全性，可以设计Refresh Token只能被使用一次，具体逻辑如下：

• 用户登录时，生成Refresh Token并存储到Redis中（用用户ID作为键，Refresh Token作为值），同时返回给前端。
• 当用户使用Refresh Token刷新Access Token时，先验证Redis中存储的该用户的Refresh Token是否与请求中的一致：
  • 若一致，生成新的Refresh Token，替换Redis中存储的旧值，同时将旧Refresh Token加入黑名单（或直接删除旧值），并返回新的Access Token和新Refresh Token。
  • 若不一致，说明该Refresh Token已被使用过或无效，直接拒绝请求。
    这种机制能避免Refresh Token泄露后被多次利用，即使旧Token未过期也无法再使用。

3. 前端配合的补充处理 #

• 前端登出时，除了移除Cookie中的Refresh Token，还要确保清除所有可能存储Token的地方（比如localStorage、sessionStorage、内存缓存等），避免前端残留的Token被意外复用。
• 建议将Refresh Token存储在HttpOnly、Secure、SameSite=Strict的Cookie中，减少XSS攻击导致Token泄露的风险，同时前端无法直接读取该Token，降低误操作的概率。

注意事项 #

• Redis黑名单的性能：使用Redis的Set或Hash结构存储黑名单，确保查询操作的效率；利用Redis的过期时间自动清理失效的黑名单条目，避免内存占用过高。
• 签名验证优先级：无论是否在黑名单中，Refresh Token的签名有效性和过期时间都必须先验证，再检查黑名单，避免无效Token占用Redis资源。

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