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

image.png

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

image.png

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

image.png

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

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

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

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

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

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

image.png

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

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

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

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

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