【通俗易懂】JWT- 使用的可能正确姿势

JWT，英文全称 JSON Web Token，一种开放行业标准。

应用场景为单点登录，API 授权等。

假想的黑粉：“所以这篇文章是要详细介绍 JWT 是什么吗？”

非也非也，如果各位看官还不了解什么是 JWT 以及 JWT 的工作流程，还请自己先去 GOOGLE 下哈

我是不会跑题的，准备愉快地进入主题

JWT 的优点：用户会话信息保存在客户端，服务端再也不用操心用户的会话信息，即服务端无状态

JWT 的缺点：只能被动等到 token 过期，不能主动失效 token

假想的黑粉：“这个缺点有啥影响吗？”

当然啦，想想退出登录，是不是就是一种主动失效的应用场景

假想的黑粉：“好像是，但这个容易解决啊，把 token 保存在后端服务，如 redis，退出时在 redis 中把它干掉不就完事了吗”<（￣︶￣）>

可以啊，脑袋转得这么快，好像可以解决问题

等等，好像哪里不对，这样又把会话信息存放在服务端，JWT 的优势木有了，那要它何用？用传统的 session 方案就行了啊

简单讲讲服务端有状态的传统 session 方案：用户登录后，服务端把用户会话信息存放在 session 中（保存在服务端的某个地方，例如缓存），然后把 session ID 存放于 cookie 中，后续用户的请求中都会携带 cookie，服务端通过 cookie 中的 session ID 即可判断用户的登录状态

假想的黑粉：“能解决问题就行，那么纠结干嘛呢？”

这。。。不行不行，不能为了用而用啊

假想的黑粉：“那你有解决方案吗？弃 JWT 而用 session？”

我觉得吧，还是有使用的可能正确姿势的，先来个华丽丽的分隔线

先来简单看一下 JWT 校验 token 的原理：

• 签名：数据 + 密钥 => Hash

• 验证：数据 + 密钥 => hash => compare 携带的签名

由上图可见存放于服务端的密钥只要不被窃取，数据就无法被篡改，一旦修改了数据，则compare步骤一定不通过，则该 token 无效

假想的黑粉：“哦，我知道了，那就篡改数据，token 自动就失效了”

你不是认真的吧？在客户端修改？Oh no！在服务端修改？Oh no！

假想的黑粉：“难道是修改密钥？密钥可是全局共用的哦，一经修改，其它颁发的 token 也跟着失效，这可是灾难性的”

差不多猜对了，全局不行，那就不要全局，来个一一对应， 一个用户专属一个唯一的密钥。

当要主动失效 A 用户的 token，只要修改 A 用户所对应的密钥即可，仔细想想，这个方案其实挺优雅的，只是稍微修改了下密钥的获取方式，JWT 的优势可以继续发挥，我们来用下图作个形象的理解吧

token 验证流程比全局密钥的模式多了一步：从 Cache 中取出某个用户的密钥。是否会对性能造成影响，就需要在实际的应用场景中进行评估了

好了，到此结束，谢谢观看

假想的黑粉：“等等啊，我想问续期怎么破啊，比如 API 授权续期问题”

续期问题可用：失效 token，重新获取新 token 的来解决

好的，真的要结束了，拜拜拜拜。。。