2021-04-28JWT用户主动注销、强制登出、忘记密码、修改密码 解决方案思考

最近在用JWT 做登录方案，由于JWT先天原因，使得JWT具有无法主动过期的缺陷。网上查了很多的关于主动注销销的策略想法，无非都是些redis的白名单，黑名单的这种方法。个人觉得，这些手法都不太优雅。于是自己琢磨了一个关于JWT的主动注销方案。

jwt 是个秘钥签发方案。能解决登陆的无状态问题。不过由于状态都是保存在客户端的，当在秘钥的有效期内。出现了，客户主动注销，修改密码，新客户端登陆，强制下线等状态时。虽然客户端删除了保存的秘钥，但对于服务端来说。该秘钥依旧是有效地 。这就可能造成一定的被攻击的机会。

关于这个问题，很多人也提出了一些解决方案。比如过期时间尽量短，加注销的白名单等。但这也损失了一部分JWT 的本来的特点优势。如何在保证JWT特点的同时，又能避免上述缺点的发生了。我捉摸了一个相对比较好的方案。

在做JWT的登陆校验过程中，大概是这样一个流程：
1、校验token 是否合法
2、token 是否过期
3、用户ID 是否存在。

我们要进行是否注销判断，也就是得在这三个主要的校验方法里增加。
我的解决方案是，在用户表当中加入一个 status_login 字段。
如果有注销，退出登陆等，则status_login则为0。修改密码，则重新生成一个字符串，并返回客户端。
如果有登陆，则status_login则修改为一个随机字符串。并把这个随机字符串添加到jwt 的载荷当中。
验证用户是否存在的时候。携带u_id 和status_login进行数据库查询对比。如果没有，则这数据就被注销了。
这是保证性能的情况的解决方案。

如果再严谨点，则就需要牺牲一部分性能。
再做token 合法验证的时候，把前端status_login字段和后端的status_login进行替换。如果校验通过，则这个客户的token的登陆时合法的，否则就是被非法的token状态。

这些是我的个人一家之言，如果有更好的解决方式，欢迎大家在评论里讨论。