为什么不推荐用JWT保护你的Web应用

上一篇文字，简单的介绍了restful项目的安全方案，有提到jwt的方式，但是不推荐使用jwt来保护web应用，记住是web应用。为什么呢？

回顾安全

认证 / 授权

• 认证（Authentication）：验证目标对象身份。比如，通过用户名和密码登录某个系统就是认证。
• 授权（Authorization）：给予通过验证的目标对象操作权限。
  更简单地说：

认证解决了「你是谁」的问题。
授权解决了「你能做什么」的问题。

对于一般的web应用，我们知道 HTTP 是无状态的，所以客户端和服务端需要解决的如何让之间的对话变得有状态。例如只有是登陆状态的用户才有权限调用某些接口，那么在用户登陆之后，需要记住该用户是已经登陆的状态。常见的方法是使用 session 机制
常见的 session 模型是这样工作的：

image.png

• 用户在浏览器登陆之后，服务端为用户生成唯一的 session id，存储在服务端的存储服务（例如 MySql, Redis）中
• 该 session id 也同时返回给浏览器，以 SESSION_ID 为 KEY 存储在浏览器的 cookie 中
• 如果用户再次访问该网站，cookie 里的 SESSION_ID 会随着请求一同发往服务端
  服务端通过判断 SESSION_ID 是否已经在 Redis 中判断用户是否处于登陆状态

理论上来说 ，JWT 机制可以取代 session 机制。用户不需要提前进行登陆，后端也不需要 Redis 记录用户的登陆信息。客户端的本地保存一份合法的 JWT, 当用户需要调用接口时，附带上该合法的 JWT，每一次调用接口，后端都使用请求中附带的 JWT 做一次合法性的验证。这样也间接达到了认证用户的目的

然而 JWT 真的能取代 session 机制吗？这么做有哪些好处和坏处？

JWT 的目的不是为了隐藏或者保密数据，而是为了确保数据确实来自被授权的人创建的（不被篡改）

回想一下，当你拿到 JWT 时候，你完全可以在没有 secret 的情况下解码出 header 和 payload，因为 header 和 payload 只是经过了 base64 编码（encode）而已，编码的目的在于利于数据结构的传输。虽然创建 signature 的过程近似于加密 (encrypt)，但本质其实是一种签名 (sign) 的行为，用于保证数据的完整性，实际上也并且并没有加密任何数据

JWT在web应用中的缺陷

缺点一： 无法满足注销场景

传统的 session+cookie 方案用户点击注销，服务端清空 session 即可，因为状态保存在服务端。但 jwt 的方案就比较难办了，因为 jwt 是无状态的，服务端通过计算来校验有效性。没有存储起来，所以即使客户端删除了 jwt，但是该 jwt 还是在有效期内，只不过处于一个游离状态。

缺点二： 无法满足修改密码场景

修改密码则略微有些不同，假设号被到了，修改密码（是用户密码，不是 jwt 的 secret）之后，盗号者在原 jwt 有效期之内依旧可以继续访问系统，所以仅仅清空 cookie 自然是不够的，这时，需要强制性的修改 secret。

缺点二： 无法满足token续签场景

我们知道微信只要你每天使用是不需要重新登录的，因为有token续签，因为传统的 cookie 续签方案一般都是框架自带的，session 有效期 30 分钟，30 分钟内如果有访问，session 有效期被刷新至 30 分钟。但是 jwt 本身的 payload 之中也有一个 exp 过期时间参数，来代表一个 jwt 的时效性，而 jwt 想延期这个 exp 就有点身不由己了，因为 payload 是参与签名的，一旦过期时间被修改，整个 jwt 串就变了，jwt 的特性天然不支持续签！

JWT应用场景

一次性验证

比如用户注册后需要发一封邮件让其激活账户，通常邮件中需要有一个链接，这个链接需要具备以下的特性：能够标识用户，该链接具有时效性（通常只允许几小时之内激活），不能被篡改以激活其他可能的账户

这种场景就和 jwt 的特性非常贴近，jwt 的 payload 中固定的参数：iss 签发者和 exp 过期时间正是为其做准备的。

总结

Web 应用中使用 JWT 是让应用变得更复杂了。在 web 应用中，绝大多数情况下，传统的 cookie-session 机制工作得更好。jwt 适合做简单的 restful api 认证，颁发一个固定有效期的 jwt，降低 jwt 暴露的风险，不要对 jwt 做服务端的状态管理，这样才能体现出 jwt 无状态的优势。