前言
前面的几篇文章讲了很多 JWT 的优点，但作为技术人员都知道，没有一种技术是万能的 "银弹"，所谓有矛就有盾，相比 Session、Cookie 等传统的身份验证方式，JWT 在拥有很多优点的同时，也有着不可忽视的缺点，比如：
JWT 的缺点
无法撤销
一旦 JWT 被发放给客户端，在有效期内这个 Token 就一直有效，无法被提前撤回
体积大，吃带宽
JWT 中包含了一些额外的信息，可能会使得 JWT 体积较大，增加网络传输开销
安全性比较差
JWT 中的信息是以明文形式存储的，容易被破解
一些解决的思路
1. 无法撤销 的解决思路
- 在用户表中增加一个整数类型的列 JWTVersion，它代表最后一次发放出去的令牌的版本号；
- 每次登录、发放令牌的时候，都让 JWTVersion 的值自增，同时将 JWTVersion 的值也放到 JWT 的负载中；
- 当执行禁用用户、撤回用户的令牌等操作的时候，让这个用户对应的 JWTVersion 的值自增；
- 当服务器端收到客户端提交的 JWT 后，先把 JWT 中的 JWTVersion 值和数据库中的 JWTVersion 值做比较，如果 JWT 中 JWTVersion 的值小于数据库中 JWTVersion 的值，就说明这个 JWT 过期了，这样就实现了 JWT 的撤回机制。
总结：
这个方案在用户表中保存了 JWTVersion 值，因此它本质上仍然是在服务器端保存状态，这是绕不过去的，它算是一种缺点比较少的妥协方案，相类似的方案还有比如维护一个 Token 黑名单的办法，相对步骤比较多
2. 体积大，吃带宽 的解决思路
-
精简 JWT 中的信息，只存储必要的信息。将一些非敏感且不经常变动的信息存储在服务端，而不是每次都包含在JWT中
-
设置较短的 JWT 过期时间，减少 JWT 的有效期，从减小 JWT 的体积
-
传输时对 JWT 进行压缩，减小 JWT 的大小，常见的压缩算法包括 GZIP 和 DEFLATE
-
在使用对称加密算法时，可以选择较小的密钥长度，减小 JWT 的大小
-
选择更高效的加密算法和签名算法，减小 JWT 的大小
-
定期清理过期的 JWT，避免过多无效 JWT 的存储占用带宽
3. 安全性比较差 的解决思路
- 不在 JWT 中存储敏感信息，如密码等，降低信息泄露的风险
- 将 JWT 中的信息放在 Redis 上，Token 只放相应的 key，服务端拿到 token 后，再到 Redis 取具体的信息并反序列化为对象