前言

前面的几篇文章讲了很多 JWT 的优点，但作为技术人员都知道，没有一种技术是万能的 “银弹”，所谓有矛就有盾，相比 Session、Cookie 等传统的身份验证方式，JWT 在拥有很多优点的同时，也有着不可忽视的缺点，比如：

JWT 的缺点

无法撤销

一旦 JWT 被发放给客户端，在有效期内这个 Token 就一直有效，无法被提前撤回

体积大，吃带宽

JWT 中包含了一些额外的信息，可能会使得 JWT 体积较大，增加网络传输开销

安全性比较差

JWT 中的信息是以明文形式存储的，容易被破解

一些解决的思路

1. 无法撤销 的解决思路

1. 在用户表中增加一个整数类型的列 JWTVersion，它代表最后一次发放出去的令牌的版本号；
2. 每次登录、发放令牌的时候，都让 JWTVersion 的值自增，同时将 JWTVersion 的值也放到 JWT 的负载中；
3. 当执行禁用用户、撤回用户的令牌等操作的时候，让这个用户对应的 JWTVersion 的值自增；
4. 当服务器端收到客户端提交的 JWT 后，先把 JWT 中的 JWTVersion 值和数据库中的 JWTVersion 值做比较，如果 JWT 中 JWTVersion 的值小于数据库中 JWTVersion 的值，就说明这个 JWT 过期了，这样就实现了 JWT 的撤回机制。

总结：
这个方案在用户表中保存了 JWTVersion 值，因此它本质上仍然是在服务器端保存状态，这是绕不过去的，它算是一种缺点比较少的妥协方案，相类似的方案还有比如维护一个 Token 黑名单的办法，相对步骤比较多

2. 体积大，吃带宽 的解决思路

1. 精简 JWT 中的信息，只存储必要的信息。将一些非敏感且不经常变动的信息存储在服务端，而不是每次都包含在JWT中

2. 设置较短的 JWT 过期时间，减少 JWT 的有效期，从减小 JWT 的体积

3. 传输时对 JWT 进行压缩，减小 JWT 的大小，常见的压缩算法包括 GZIP 和 DEFLATE

4. 在使用对称加密算法时，可以选择较小的密钥长度，减小 JWT 的大小

5. 选择更高效的加密算法和签名算法，减小 JWT 的大小

6. 定期清理过期的 JWT，避免过多无效 JWT 的存储占用带宽

3. 安全性比较差 的解决思路

1. 不在 JWT 中存储敏感信息，如密码等，降低信息泄露的风险
2. 将 JWT 中的信息放在 Redis 上，Token 只放相应的 key，服务端拿到 token 后，再到 Redis 取具体的信息并反序列化为对象