JSON Web Tokens，又称
JWT
。本文将详解：为何 JWT 不适合存储 Session，以及 JWT 引发的安全隐患。望各位对
JWT
有更深的理解！
❝
原文地址：
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions
❞
十分不幸，我发现越来越多的人开始推荐使用 JWT 管理网站的用户会话（
Session
）。在本文中，我将说明为何这是个非常非常不成熟的想法。
为了避免疑惑和歧义，首先定义一些术语：
-
无状态 JWT（
Stateless JWT
）：包含 Session 数据的 JWT Token。Session 数据将被直接编码进 Token 内。
-
有状态 JWT（
Stateful JWT
）：包含 Session 引用或其 ID 的 JWT Token。Session 数据存储在服务端。
-
Session token
（又称
Session cookie
）：标准的、可被签名的 Session ID，例如各类 Web 框架（译者注：包括 Laravel）内已经使用了很久的 Session 机制。Session 数据同样存储在服务端。
需要澄清的是：本文并非挑起「
永远不要使用 JWT
」的争论 —— 只是想说明 JWT 并不适合作为 Session 机制，且十分危险。JWT 在其它方面的确有其用武之地。本文结尾，我将简短地介绍一些合理用途。
很多人错误地尝试比较
Cookies
和
JWT
。这种对比毫无意义，就像对比内存和硬盘一样。Cookies 是一种存储机制，然而 JWT Tokens 是被加密并签名后的令牌。
它们并不对立 —— 相反，他们可以独立或结合使用。正确的对比应当是：
Session
对比
JWT
，以及
Cookies
对比
Local Storage
。
在本文中，我将把 JWT Tokens 同 Session 展开对比，并偶尔对比
Cookie
和
Local Storage
。这样的比较才有意义。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
-
视频教程：https://doc.iocoder.cn/video/
在人们安利 JWT 时，常常宣扬以下几点好处：
我将会逐条阐述以上观点为何是错误或误导性的，其中部分解释可能会有些模糊，这主要是因为这些「好处」的表述本身就比较模糊。
这是列表中唯一一条在技术层面部分正确的「好处」，但前提是你使用的是无状态 JWT Tokens。然而事实上，几乎没人需要这种横向扩展能力。有很多更简单的拓展方式，除非你在运维像淘宝这样体量的系统，否则根本不需要无状态的会话（
Stateless sessions
）。
一些扩展有状态会话（
Stateful sessions
）的例子：
-
「在单台服务器上运行多个后端进程」
：只需在此服务器上安装 Redis 服务用于存储 Session 即可。
-
「运行多台服务器」
：只需一台专用的 Redis 服务器用于存储 Session 即可。
-
「在多集群内运行多台服务器」
：会话保持（又称：粘滞会话）。
以上所有场景在现有软件系统内都具备良好的支持，你的应用需要进行特殊处理的可能性基本为零。
或许你在想，应当为你的应用预留更多调整空间，以防未来需要某些特殊操作。但实践告诉我们，以后再替换 Session 机制并不困难，唯一的代价是，在迁移后所有用户将被强制登出一次。我们没必要在前期实现 JWT，尤其是考虑到它所带来的负面影响。
这个真没有。你不得不自行处理 Session 的管理机制，无论是客户端还是服务端。然而标准的
Session cookies
则开箱即用，JWT 并没有更简单。
说白了，目前各种开箱即用的框架并没有自动集成 JWT，需要研发人员自行处理。
我暂时还没看到有人成功地阐述「JWT 如何更加灵活」。几乎每个主流的 Session 实现，都允许你直接把数据存储进 Session，这跟 JWT 的机制并没有差别。据我所知，这只是个流行语罢了。
一大批人认为 JWT Tokens「更加安全」，理由是使用了加密技术。实际上，签名后的 Cookies 比未签名的 Cookies 同样更加安全，但这绝不是 JWT 独有的，优秀的 Session 实现均使用签名后的 Cookies（译者注：例如 Laravel）。
「使用加密技术」并不能神奇地使某些东西更加安全，它必须服务于特定目的，并且是针对该目的的有效解决方案。错误地使用加密反而可能会降低安全性。
另一个我听过很多次的对于「更加安全」的论述是「JWT 不使用 Cookies 传输 Tokens」。这实在是太荒谬了，Cookie 只不过是一条 HTTP 头信息，使用 Cookies 并不会造成任何不安全。事实上，Cookies 受到特别良好的保护，用于防止恶意的客户端代码。
如果担心有人拦截掉你的 Session cookies，那你应当考虑使用 TLS。如果不使用 TLS，任何类型的 Session 机制都可能被拦截，包括 JWT。
无意义，又没什么卵用的特性。在服务端也能实现过期控制，有不少 Session 实现就是这么做的。实际上，服务端的过期控制更加合理，这样你的应用就可以清除不再需要的 Session 数据；若使用无状态 JWT Tokens 且依赖于它的过期机制，则无法执行此操作。
这个过期时间在某些场景实际上是增加了复杂度的。
完全错误。并没有什么「Cookies 法律」—— 有关 Cookies 的各种法律实际上涵盖了任何类型「对某项服务的正常运行非严格必须的持久性 ID」，任何你能想到的 Session 机制都包括在内。
❝
译者注：然鹅中国并没有。
❞
简单来说：
-
若出于系统功能目的使用 Session 或 Token（例如：保持用户的登录态），那么无论怎样存储 Session 均无需征得用户同意。
-
若出于其他目的使用 Session 或 Token（例如：数据分析、追踪），那么无论怎样存储 Session 都需要询问用户是否允许。
这个真真的没有。存储 JWT Tokens 的方式大概有两种：
-
「存入 Cookie」
：仍然易受 CSRF 攻击，还是需要进行特殊处理，保护其不受攻击。
-
「其他地方，例如 Local Storage」
：虽然不易受到 CSRF 攻击，但你的网站需要 JavaScript 才能正常访问；并且又引发了另一个完全不同，或许更加严重的漏洞。我将在后文详细说明。
预防 CSRF 攻击唯一的正确方法，就是使用 CSRF Tokens。Session 机制与此无关。
毫无根据。目前所有可用的浏览器几乎都支持 Cookies，因此也支持 Session。同样，主流的移动端开发框架以及严谨的 HTTP 客户端库都是如此。这根本不是个问题。
不太可能。用户通常会阻止任何意义上的持久化数据，而不是只禁止 Cookies。例如，Local Storage 以及任何能够持久化 Session 的存储机制（无论是否使用 JWT）。不管你出于多么简单的目的使用 JWT 都无济于事，这是另一个完全独立的问题了。另外，试图让身份认证过程在没有 Cookies 的情况下正常进行，基本没戏。
最重要的是，禁用掉所有 Cookies 的多数用户都明白这会导致身份认证无法使用，他们会单独解锁那些他们比较关心的站点。这并不是你 —— 一个 Web 开发者应当解决的问题。更好的方案是，向你的用户们详细地解释为何你的网站需要 Cookies 才能使用。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/yudao-cloud
-
视频教程：https://doc.iocoder.cn/video/
以上，我已经对常见的误解做了说明，以及为什么它们是错误的。你或许在想：「这好像也没什么大不了的，即便 JWT 无法带来任何好处，但也不会造成什么影响」，那你真是大错特错了。
使用 JWT 作为 Session 机制存在很多缺点，其中一部分会造成严重的安全问题。
JWT Tokens 实际上并不「小」。尤其是使用无状态 JWT 时，所有的数据将会被直接编码进 Tokens 内，很快将会超过 Cookies 或 URL 的长度限制。你可能在想将它们存储到 Local Storage，然而...
若将 JWT Tokens 存储到 Cookies 内，那么安全性与其他 Session 机制无异。但如果你将 JWT 存储至其它地方，会导致一个新的漏洞，详见
https://blog.prevoty.com/does-jwt-put-your-web-app-at-risk
，尤其是「Storing sessions」这一部分。
❝
Local Storage，一个 HTML5 内很棒的功能，使浏览器支持 Key/Value 存储。所以我们应当将 JWT Tokens 存储到 Local Storage 吗？考虑到这些 Tokens 可能越来越大，或许会很有用。Cookies 通常在 4k 左右的存储时比较占优势，对于较大的 Tokens，Cookies 可能无法胜任，而 Local Storage 或许成了明确的解决方案。然而，Local Storage 并没有提供任何类似 Cookies 的安全措施。LocalStorage 与 Cookies 不同，并不会在每次请求时发送存储的数据。获取数据的唯一方法是使用 JavaScript，这意味着任何攻击者注入的 JavaScript 脚本只需通过内容安全策略检查，就能任意访问或泄露数据。不光是这样，JavaScript 并不在意或追踪数据是否通过 HTTPS 发送。就 JavaScript 而言，它就只是个数据而已，浏览器会像操作其它数据一样来处理它。在历代工程师们经历了各种麻烦之后，终于能够确保没有人可以恶意接触到我们的 Cookies，然而我们却试图忽略这些经验。这对我来说似乎是在退步。
❞
简单来说，
「使用 Cookies 并不是可选的」
，无论你是否采用 JWT。
还有更多安全问题。不像 Sessions 无论何时都可以单独地在服务端销毁。无状态 JWT Tokens 无法被单独的销毁。根据 JWT 的设计，无论怎样 Tokens 在过期前将会一直保持有效。举个例子，这意味着在检测到攻击时，你却不能销毁攻击者的 Session。同样，在用户修改密码后，也无法销毁旧的 Sessions。
