共计 1259 个字符，预计需要花费 4 分钟才能阅读完成。
JSON Web Token（JWT）作为目前最风行的跨域认证计划大家都不生疏了吧。很多零碎都在应用 JWT 代替 session 认证，这两者有啥区别呢？
简言之，JWT 是将认证后的数据保留在客户端，session 是保留在服务器端。
应用 JWT 代替 session 认证后，服务器不必保护 session，分布式环境下不须要单点存储 session。因为 JWT 的自解释性，只有验证 JWT 是否非法就 OK 啦。大大晋升了零碎的可扩展性，特地适宜当下微服务大行其道的大环境。
退出一个
然而。。。
老板想要实现踢人，封号怎么办呢？
第一个想法就是颁布 jwt 时，把 jwt 存到一个核心 redis 中。每次拜访验证 jwt 时看看 redis 里是否有这个 token，没有这个 token 就认证失败。踢人封号只用把用户关联的 jwt 删除掉就 ok 了！就能够欢快的回家抱媳妇了（道歉可能你没有）。
且慢，这么玩齐全违反了 jwt 的初衷，服务器又变了有状态了，何苦脱裤子放屁呢，间接用 session 不就完了？
讲真的 jwt 的设计也不太适宜这样的场景。
那如果咱们非要实现强制用户登出要怎么办呢？
能够采纳相似 oauth2.0 协定中的做法，认证后颁布 2 个 token，access token 和 refresh token。
- access token 拜访令牌为一个 JWT，设置一个较短的过期工夫，比方 1 小时。拜访令牌每次调用后端服务都须要携带，往返网络的频率十分高，裸露的可能性就越大，设置较短的过期工夫也能够升高平安危险。
- refresh token 刷新令牌，能够不为 JWT，设置一个较长的过期工夫，比方 1 个月。刷新令牌次要用来换取新的 access token。因为其仅在拜访令牌要生效或曾经生效时才会被传递给服务端，较长的过期工夫并不会有太大的平安危险。颁发 token 的时候，仅将刷新令牌保留在 redis 并设置过期工夫。当应用刷新令牌换取新的拜访令牌时，须要判断 redis 里是否存在该刷新令牌，如果不存在，则刷新失败，用户就须要从新登录。
客户端要长时间保护登录态，就须要当拜访令牌生效后，主动应用刷新令牌获取新的拜访令牌。或者在拜访令牌生效之前，提前刷新令牌。
当初咱们想要踢人，只须要将用户相干的刷新令牌从 redis 里删除。以后的拜访令牌生效后，天然也没有方法再刷新令牌了。从而达到强制用户登出的目标。
这么设计有个缺点就是强制用户登出不是及时的。须要有一个期待拜访令牌过期的工夫。如果心愿及时性高点，能够将拜访令牌的过期工夫设置短一点，但刷新 token 的频率就会升高。这个须要依据本人的业务进行衡量。
每次调用服务 api 时依然是原汁原味的 jwt 无状态认证，无需拜访任何核心存储。仅在刷新拜访令牌的时候须要拜访核心存储。也算是一种折中的计划。
欢送关注作者的 github 我的项目，学习微服务：
一个反对多店铺的电商零碎，基于 Spring Boot 的微服务构架
https://github.com/ikeyit/ike…
一个基于 React 的电商治理后盾
https://github.com/ikeyit/ike…
