共计 5580 个字符，预计需要花费 14 分钟才能阅读完成。
引言
近来发现，不少 WEB 利用零碎应用 JWT 进行会话治理，原因居然是为了防止服务端存储会话，或者谋求可自主管制，实不知应用 JWT 进行会话治理有微小的安全隐患！
HTTP 会话治理
先说说 HTPP 协定，家喻户晓，HTTP 协定的特点就是一问一答（一次申请一次响应）。那么基于 HTTP 协定，做个购物网站，要实现用户登录，增加商品到购物车，最终买单的性能。为了实现以上性能，辨认出一系列操作都是同一个用户，最为简略的形式就是每次操作浏览器都发送账户和明码，这样服务端晓得是哪个用户增加商品到购物车和最终买单。这样看起来很简陋，而且在每次申请中携带账户和明码将大大增加泄露危险。
为了缩小账户明码在申请中携带的次数，咱们引入一个 session-id 的货色。在你携带账户明码登录购物网站（第一次申请），服务端验证通过后返回一个 session-id。尔后你增加商品到购物车也好，最终下单也好，反正后续的每次申请都携带好这个 session-id 即可。为什么携带 session-id 就能够辨认出这是哪个客户的操作呢？因为服务端将客户的账户信息和本次会话发送给客户端的 session-id 关联了起来，那么这个 session-id 和账户的关联信息就是 session-data。
在以上例子里，session-data 是存储在服务端的。其实，session-data 也能够存储到客户端。那么依据 session-data 存储的地位不同，分为 Server Side Session 和 Client Side Session 两种模式。
Server Side Session
Server Side Session 模式是最为常见的，如后面购物网站的例子。在此模式中，客户端（浏览器）将 session-id 存储到 本地 cookies 中。其典型实现如下图所示：
上图中 User A 是个曾经建设会话的老用户，他的 Cookies 中存储了 Session_id，值为“AA01”，在申请中携带这个 Session_id，服务端收到后通过 Session_id 查问到 Session Database 中对应的数据，并在程序中应用。New User 是个刚开始会话的新用户，他的 Cookies 中还没有 Session_id，于是服务端生成一个新的 session_id 返回给他，并在返回中应用 401 状态码，告知他重定向到登录页，进行登录。后续如果这个 New User 登录胜利，服务端将会把他的身份信息存储到 Session Table 中，并与会话初生成的 session_id 关联，这样后续的申请就如同 User A 这个老用户。
Client Side Session
Client Side Session 模式大家可能感觉有点生疏，其实用的很多。如大部分应用 JWT 进行会话治理的 WEB 零碎，就是 Client Side Session 模式。所谓 Client Side Session 模式就是把用户的 session-data 数据存储在客户端，这样服务端就十分安闲。其交互流程大抵如下图所示：
上图中左侧 User A 是个曾经建设会话的老用户，他的 Cookies 中存储了 Session_data，值为以后用户的根本信息，在申请中携带着 Session_data 数据，服务端收到申请后解析出 Session_data 信息，便晓得是哪个用户的申请。右侧的 New User 用户正在登录建设会话，服务端验证胜利后，将生成 session_data 信息，返回给客户端。因为 session_data 数据是存储在客户端，为了避免篡改，服务端会对生成的 session_data 数据进行签名，甚至加密。
Server Side VS Client Side
前文介绍了 Server Side Session 和 Client Side Session 两种模式各自的原理，那么这两种模式孰优孰劣呢？在比照之前，先定一个基准，就是仅限 功能性 和安全性，而不是比照两种模式的原始实现性。
Server Side Session
长处：
- 会话数据存储在服务端，不裸露相干信息，安全性高；
- 每次申请只需传递 session-id，缩小流量开销；
- 服务端可不便撤消会话，管制同账户会话并发数等全面的会话策略管理；
毛病：
-
服务端分布式部署时，需减少解决 Session-data 共享。
Client Side Session
长处：
- 扩散存储；
毛病：
- 会话数据存储在客户端，且在每次申请中携带，减少泄露危险；
- 每次申请需传递更多数据，减少流量开销；
- 服务端不不便撤消会话，实现各种会话策略管理；
从以上比照能够看出，两种模式在 功能性 和安全性 上的特点刚好相同。Server Side Session 模式长处突出，但为什么还存在 Client Side Session 模式呢？所谓存在即正当，因为 Client Side Session 模式 原始实现简略 ！Client Side Session 模式服务端无需集中存储 session-data 数据，天然也无需解决 session-data 的查找，而且扩散存储在客户端，服务端无需思考分布式下的 session-data 共享。
然而 Client Side Session 模式原始实现简略对于使用者来说并不重要，因为使用者只应用现成的库和框架，只有反对度好就行。所以，Server Side Session 比 Client Side Session 模式更为广泛。
什么是 JWT？
首先阐明 JWT（JWE、JWS）规范只是设计了一个防篡改令牌，并非是为会话治理而设计。
JSON Web Token(JWT)是一个基于 RFC 7519 的凋谢数据规范，它定义了一种宽松且紧凑的数据组合形式，应用 JSON 对象在各利用之间传输信息（信息加密即 jwe，签名即 jws）。该 JSON 对象能够通过数字签名进行鉴签和校验，个别地，JWT 能够采纳 HMAC 算法，RSA 或者 ECDSA 的公钥 / 私钥对数据进行签名操作。一个 JWT 通常有 HEADER (头)，PAYLOAD (有效载荷)和 SIGNATURE (签名)三个局部组成，三者之间应用“.”链接，格局如上图所示。
JWT 的缺点
JWT 规范设计看起来很不错，实际上包藏祸心，因为其设计，暗藏诸多平安问题，具体如下：
重置空加密算法缺点
JWT 反对将算法设定为“None”，如果你应用 JWT 库时未设置敞开该性能，那么任何 Token 都是无效的。具体做法是将 JWT 第一局部 header 中 alg 字段设置为 None，再将第三局部 signature 设置为空（即不增加 signature 字段），此 token 可顺利通过验证。
密钥混同攻打
JWT 最罕用的两种算法是 HMAC 和 RSA。HMAC（对称加密算法）用同一个密钥对 token 进行签名和认证。而 RSA（非对称加密算法）须要两个密钥，先用私钥加密生成 JWT，而后应用其对应的公钥来解密验证。如果公钥泄露（很多人感觉公钥能够散发），那么将算法 RS256 批改为 HS256，即非对称加密向下降级为对称加密。再应用这个泄露的公钥对 token 进行签名，后端收到后依据头中指定的算法，将应用公钥对 token 验证，如此便认证通过。
密钥暴力破解
如果 JWT 应用对称加密算法（如 HS256），这意味着对令牌进行签名的密钥也用于对其进行验证。因为签名验证是一个自蕴含的过程，因而能够测试 token 自身的无效密钥，而不用将其发送回应用程序进行验证。如果密钥设置过于简略，如罕用词汇、生日年份等，联合已知的泄露明码列表，将很快破解出密钥，如此便可伪造出任意 token。
kid 指定攻打
kid 即为 key ID，存在于 jwt header 中，是一个可选的字段，用来指定加密算法的密钥。如在头部注入新的 kid 字段，并指定 HS256 算法的 key 为 123456，生成新的 token, 服务端收到将应用指定的密钥 123456 来验证 token。
如何防止 JWT 的缺点
以上列举的问题中，除了密钥暴力破解，其余皆为 jwt 规范设计引发的缺点。如果你抉择应用 jwt 规范，那么请找一个靠谱的实现库，并进行平安测试。请防止应用对称加密算法，并正确配置平安项，如开启验证 jwt 头部，禁止 alg 设置为 none，禁止密钥降级等安全措施。不过最好的防止形式就是不必 jwt，改用 paseto，一个代替 jwt 的新规范。
JWT 进行会话治理的“长处”
首先，如前文所述，JWT 规范并非是为会话治理而设计，当然 paseto 规范（JWT 规范的替代者）也不是。现如今大多数应用 JWT 进行会话治理实际上是 Client Side Session 模式。前文讲到 Client Side Session 模式将会话数据存储到客户端，那么为了避免数据篡改或者泄露，个别对存储在客户端的数据进行签名或加密。很多人就利用 JWT 实现库将会话数据放在 PAYLOAD 区域，而后生成一个 token，发送给客户端。客户端如果是网页浏览器，甚至通过 js 将收到的 token 搁置在 localStorage 中。以上操作让开发者感觉所有尽在把握之中，殊不知集万千破绽于一身。
应用 JWT 进行会话治理的人宣称长处如下：
- 人造反对分布式验证；
- 高并发下升高服务器压力；
- 灵便易用；
- 更平安，可避免 CSRF；
- 在挪动设施上成果更好；
- 实用于阻止 cookie 的用户。
以上宣称的长处实际上是 Client Side Session 模式和自主管制 token 带来的。然而我要通知各位，对于使用者来说，以上长处全副是伪命题。
人造反对分布式验证
这个特点是真的，然而现实情况是简直没有人真正须要这个特点。因为 session 共享技术很成熟，现有软件框架都提供了良好的反对计划。
高并发下升高服务器压力
看上去高并发下，Client Side Session 模式没有服务端存储和查问，可升高服务器压力。然而，如果真的是高并发，更应该思考业务解决对服务器带来的压力，而不是会话存储和查问，因为这根本就是沧海一粟。
灵便易用
这齐全是个谬误，自定义应用 JWT 进行会话治理，须要更多的代码配置来解决，何来灵便易用？
更平安，可避免 CSRF
前文介绍 JWT 规范，已阐明 JWT 存在很多设计问题，更不用说 Client Side Session 模式带来信息泄露的危险。而对于能够避免 CSRF，除非你把 token 放在 cookies 以外区域，如 localStorage 中，应用 JS 来操作，然而这将带来更大的危险。
在挪动设施上成果更好
很久以前，局部挪动浏览器存在不反对 cookie 的状况，但这曾经是过来式了。当初但但凡个靠谱的 HTTP 库，挪动开发框架都反对 cookie，所以这基本不是个问题。
实用于阻止 cookie 的用户
的确有用户会阻止 cookie 的应用，为了防止被跟踪。但建设会话就是要求登录验证身份信息，所以，抉择阻止 cookie 应用的用户明确，为什么我登录不了。对于真心想防止跟踪的用户，不仅仅会阻止 cookie，而是会阻止所有客户端存储。这样，Client Side Session 模式下，会话信息也是无处可存。
如果你偏爱 Client Side Session 模式，而且的确感觉 Client Side Session 模式能够满足你的需要，那仅需应用服务端框架反对的 Client Side Session 模式实现即可，而不用去应用 JWT。
HTTP 会话治理的正确之道
对于平安会话，首先是须要应用 HTTPS，用于保障传输通道的平安。而后应用 Server Side Session 模式的实现，如网页浏览器中的 cookie 存储随机标识符，即 session-id，该 session-id 与服务端存储的 session-data 配对。如果你须要放弃更久的会话，可退出一个长期的 remember me id 来实现，而不是随便缩短 session-id 的有效期。
有敌人说，JWT 会话治理可通过扩大防止 Client Side Session 模式下的毛病。如撤消会话，服务端可退出黑名单机制，或者服务端记录签发进来的 token，并设置有效期，而后每次申请进行比对。那么问题来了，这样还是 Client Side Session 模式吗？
补充
有敌人说 JWT 非常简单的实现了单点登录，一问到底，我竟无言以对。原来他是指多个系统配置一样的密钥进行 token 验证，即可实现零碎间无缝身份验证。没错，这其实就是 Client Side Session 模式的长处，在特定场景下可实现“单点登录”的成果。但事实大多数场景下是不可能达成的，因为首先须要各个不同公司开发的软件系统都采纳 JWT 进行会话治理，接着相互信赖共享同一个密钥（这是极其不平安的）。当初支流解决单点登录的协定是 OIDC 或者是 OAuth2，再古老些也是 SAML 或 CAS。
有敌人问，既然 JWT 并不是为会话治理设计的，那 JWT 应该用来做什么？JWT 实用于一次性令牌，即短有效性，一次性应用。如用于密码找回邮件中的短效一次性链接，或者是文件下载。
参考文献
[1] [EB/OL].http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/.2021-05-04
[2] paseto [EB/OL].https://github.com/paragonie/paseto/.2021-05-04
[3] [EB/OL].https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid.2021-05-04
[4] [EB/OL].https://geekkeen.github.io/http-cookie-session.html.2021-05-04
[5] [EB/OL].https://blog.by24.cn/archives/about-session.html.2021-05-04