JWT的学习（3）之解决JWT无法提前撤回的难题

一.TWT的缺点

JWT把用户信息保存到客户端，而不像Session那样在服务器端保存状态，因此更加适合分布式系统及前后端分离项目，但任何技术都不是完美的。缺点是一旦 JWT 被发放给客户端，在有效期内这个令牌就一直有效，令牌是无法被提前撤回的。哪些场景会需要在 JWT 过期之间提前撤回令牌呢?比如，用户被删除了，那么针对这个用户的令牌就要被撤回，否则会出现客户端使用已经被删除的用户身份的问题;再如，某个 JWT 被恶意攻击者拿到并用来发送恶意请求，我们也要撤回针对这个用户的令牌，以便阻断攻击者;再如，用户在 A设备上登录了，稍后又在B设备上登录了，我们就需要把用户在 A设备上登录获得的 JWT 撤回，否则就会出现用户同时在多个设备上登录的问题。

上面提到的这些需求其实用传统的Session 实现更合适，因为这些需求都是和“服务器端保持状态”相关的，而 JWT 是一种服务器端无状态的机制。如果既要用 JWT，又要解决过和服务器端保持状态相关的问题，显然是缘木求鱼。不过考虑到 JWT 已经成为现在新的事实上的标准，如果项目不能改为用传统 Session 机制的话，我们就仍然需要寻找JWT下的实现方式。网上有很多解决方案，比如用 Redis 保存状态，或者用 refresh_token+access_token 机制等。

我这是另一个解决方案，解决方案的思路是:在用户表中增加一个整数类型的列 JWTVersion，它代表最后 一 次发放出去的令牌的版本号;每次登录、发放令牌的时候，我们都让 JWTVersion 的值自增,

同时将 JWTVersion 的值也放到 JWT的负载中;当执行禁用用户、撤回用户的令牌等操作的时 候，我们让这个用户对应的JWTVersion 的值自增;当服务器端收到客户端提交的JWT后，先把JWT 中的 JWTVersion 值和数据库中的 JWTVersion 值做比较，如果JWT中JWTVersion的 值小于数据库中 JWTVersion 的值，就说明这个 JWT 过期了，这样我们就实现了 JWT 的撤回 机制。由于我们在用户表中保存了 JWTVersion 值，因此这种方案本质上仍然是在服务器端保 存状态，这是绕不过去的，只不过这种方案是一种缺点比较少的妥协方案。

二.JWT的实例

之前写的Identity项目

MyRole实体类

MyUser实体类

MyDbContext类