不懂就问，请教一下前端无感刷新 token 到底有没有意义？

@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 时，发现不可用了，再进行退出。

所有用无限期的 token 的时候都一定有过临时 token 。比如后台某个服务/脚本临时用个 token 。。然后时间长了，这个 token 就无法改了，特别的蛋疼。token 就应该是无状态的，一定时间内轮换。不然请用 cookie/session 机制。

另一方面。我就在我之前公司 app 上碰到过。无聊的黑客，登陆了就拿着 token 无限制的做任何事。等你发现的时候已经受损失了。如果是双 token 机制，上线的时候就会把访问频率考虑进去。单 token 的，大部分程序员应该实现的就是又不是不能用策略。。防刷？想啥呢。。。

纯粹就是为了性能，和安全性/分布式什么的一点关系都没有。
at 是离线校验，不读数据库。
rt 是在线校验，需要访问数据库。
假设某种业务每个小时访问接口 1000 次，at 有效期 1 个小时。此时每个小时可以省 999 次访问数据库。只有过期的那次才需要刷一下

针对新的疑问：
1. 不通知；
2. 只能等待过期，所以才设计较短的有效期来一定程度上规避安全风险。

看到一个银行的实现，accessToken 有效期 2 分钟

小业务规模上，直接签一年的

refreshToken 我的看法是只是给 jwt 打个补丁，jwt 这东西它就不适合用来做用户登录。用户登录还是老老实实用 session 吧。

鉴权方案有很多种，JWT 属于很辣鸡的那类。云厂商喜欢用 api_key 标识账户，api_secret 对参数签名，生成一次性的 token

acessToken 用来感知用户是否在线

jwt 只是鉴权方案的一种形式，也不一定要用。

无意义，直接用服务端 token ，jwt 只适合一次性授权