增加操作空间吧，如果后端什么监控和防护措施都没有，那就是脱裤子放屁，去你所说 rt 被抓包了等于密码泄露。但是如果加了防护措施可以规避异常访问，用的来说就是在用户体验与安全性的折中做法。。

@purringpal 错别字: 如你所说、总的来说

以前应该很香，现在看应该算是裹脚布 又长又臭

这是为了缓解 OAuth2 在实际应用中的一个主要缺陷，通常访问令牌一旦发放，除非超过了令牌中的有效期，否则很难（需要付出较大代价）有其他方式让它失效，所以访问令牌的时效性一般设计的比较短，譬如几个小时，如果还需要继续用，那就定期用刷新令牌去更新，授权服务器就可以在更新过程中决定是否还要继续给予授权。 -- 凤凰架构

accessToken 、refreshToken 双 Token 只在分布式|微服务架构下有意义。 考虑我们有用户微服务和订单微服务，我们把用户信息存储在用户微服务，向订单微服务发起请求时需要验证用户有效性： 1. 如果使用单 token 方案，订单微服务接到请求时 需要向用户微服务发起询问来验证用户有效性，在这一步至少需要一次网络通信。 2. 如果使用双 token 方案，向用户微服务发起请求时携带 refreshToken ，向订单微服务发起请求时携带 accessToken ，accessToken 过期时向用户微服务发起请求重写签发 accessToken 。 accessToken 具有以下特性： · 明文：这允许订单微服务直接从 accessToken 读取用户信息而不必询问用户微服务； · 具备签名：这允许订单微服务直接验证 accessToken 的有效性而不必询问用户微服务； · 不可篡改：这使得 accessToken 一经用户微服务签发则在有效期内一直有效，当用户更改密码或其他需要重制登录状态的时候 accessToken 也不受影响，为了满足重制登录状态的需求 accessToken 的有效期一般比较短。 总结一下，双 token 方案使得订单微服务微服务不用向用户微服务发起询问，代价是 accessToken 不可篡改、登录状态难以清除。 回答楼主的问题： 1. refreshToken 只能向用户微服务发起请求，订单微服务无法验证 refreshToken 的有效性； 2. 是的； 3. accessToken 不可篡改，不可延时； 个人看法：双 token 方案带来的「无需向认证服务询问」的特性有一点点优势；但很多场景会有下「踢出用户」的需求，这时候使用双 token 要么等着 accessToken 过期，要么向认证服务发起询问，前者实时性低，后者让损失了 双 token 方案唯一的优势。我的建议是摒弃双 token 方案，使用单 token 存 redis ，认证服务和业务服务都直接从 redis 读取用户状态。

讲真, 我觉得还不如那个脱裤子放屁的操作: 加一道 redis 检验, 判断应该 401 还是正常使用, 既使用了 jwt 的简单粗暴, 又成功把部分数据库压力转移到内存去.

这个话题展开讲的话内容太多了，简单说就是一切还是要回归到你的业务需求上，rt 存在本身肯定是有意义的

安全性考虑，在 JWT 场景，at 有效期不能太久，因为无法踢掉。rt 重新签发，能做一些安全校验。

去年实习的时候有在掘金提过类似的问题，也是关于双 token 的意义的。实习公司做的小项目也要上双 token ，到现在仍旧没有一个能够彻底说服我的理由。

类 JWT 场景下，at 是用签名来验证，而不用实际比对数据库。当发生某些需要 revoke token 的场景时，如果 at 的有效期足够短，可以不实现。等到过期校验 rt 时，发现不可用了，再进行退出。