使用JWT，封号，踢人，强制用户退出到底怎么实现？

Posted 2023-03-25

参考技术A 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。

客户端要长时间维护登录态，就需要当访问令牌失效后，自动使用刷新令牌获取新的访问令牌。或者在访问令牌失效之前，提前刷新令牌。
现在我们想要踢人，只需要将用户相关的刷新令牌从redis里删除。当前的访问令牌失效后，自然也没有办法再刷新令牌了。从而达到强制用户登出的目的。
这么设计有个缺陷就是强制用户登出不是及时的。需要有一个等待访问令牌过期的时间。如果希望及时性高点，可以将访问令牌的过期时间设置短一点，但刷新token的频率就会升高。这个需要根据自己的业务进行权衡。
每次调用服务api时仍然是原汁原味的jwt无状态认证，无需访问任何中心存储。仅在刷新访问令牌的时候需要访问中心存储。也算是一种折中的方案。

欢迎关注作者的github项目，学习微服务：
一个支持多店铺的电商系统，基于Spring Boot的微服务构架
https://github.com/ikeyit/ikeyit-services
一个基于React的电商管理后台
https://github.com/ikeyit/ikeyit-management-web