JWT解决了什么问题
存储token的情况：校验token需要重复调用数据库耗时的问题
JWT本身缺陷
- alg不要指定为none
- 算法不要指定数组，只使用一种算法
- 令牌长度可能会超过允许的URL长度，和cookie长度
- 如果需要跟踪用于速率限制和 IP 白名单的 API这些功能，那么使用无状态是不现实的
以上都是容易避免的问题，JWT 最大的问题是令牌撤销问题。因为它
在过期前一直有效，因此服务器没有简单的方法来撤销它。
以下是一些可能导致令牌撤销问题的案例：
- 注销并不是真正注销。想象一下，你在发送完推文后注销了 Twitter。你会认为自己 注销了服务器，但事实并非如此，因为 JWT 是自包含的，在过期前都将继续工作。过期。过期时间可能是 5 分钟或 30 分钟，也可能是令牌中设定的任何时间。因此，如果有人 可以继续使用它进行身份验证，直到过期为止。
- 阻止用户不会立即阻止他们。想象一下，你是 Twitter 或某些在线实时游戏的版主，在这些游戏中，真实用户正在使用系统。游戏的版主，真实用户正在使用该系统。作为版主，您想快速阻止某人滥用系统。系统。出于同样的原因，你不能这样做。即使你阻止了他们，该用户仍可继续访问服务器，直到令牌过期。
- JWT 可能包含过期数据。比如，用户是管理员，却被降级为权限较少的普通用户。同样，这不会立即生效，用户将继续是管理员，直到令牌过期。
- JWT 通常没有加密。正因为如此，任何能够执行中间人攻击并嗅探 JWT 的人 现在就能获得你的身份验证凭据。由于中间人攻击只需在服务器和客户端之间的连接上完成，因此这变得更加容易。因为 MITM 攻击只需在服务器和客户端之间的连接上完成。有一种加密 JWT 令牌的方法叫 JWE，但使用这种方法时，客户端（尤其是浏览器和 移动设备）无法对其解密，也就无法看到实际的有效负载。此时，您基本上是将 JWT 作为普通的加密会话令牌–至少从网络应用程序和移动应用程序的角度来看是这样。
使用Redis规避JWT的缺陷
就需要结合Redis使用，既解决了数据库来回请求慢（Redis快）的问题，又解决了JWT令牌撤销问题。
Redis + JWT消除了之前讨论过的大部分安全问题（中间人攻击除外）。可以 可以使用 JWT 作为初步检查，同时使用Redis 作为辅助检查（只是判断token是否存在）。
在这种情况下，如果 JWT 校验成功，服务器仍会转到 Redis对信息进行双重检查。如果JWT 验证本身失败，就不必担心检查 Redis 数据库。
这种方法的另一个好处是，你可以在前台使用前端和后端现有的 JWT 库而不必开发自己的自定义方式将数据存储在 Redis 中（尽管这并不是什么大问题）。
最后需要注意的一点是，如上所述、 这种设置仍会使应用程序受到潜在的 中间人攻击。因为令牌没有加密。
如前所述，有一种对 JWT 令牌进行加密的方法叫做 JWE，但使用这种方法时，客户端 (尤其是浏览器和移动设备）无法解密来查看实际有效负载。此时您基本上是将 JWT 用作普通的加密会话令牌，至少从网络应用程序和移动应用程序的角度来看。
如果您要将它用于机器对机器通信，比如在微服务中要在两个不同的服务之间共享登录信息时，就可以共享公钥来解密和查看 JWT 数据–但这是不同的用例。
