请立刻停止使用 JWT 进行会话管理

引言

近来发现，不少 WEB 应用系统使用 JWT 进行会话管理，缘由竟然是为了避免服务端存储会话，或者追求可自主控制，实不知使用 JWT 进行会话管理有巨大的安全隐患！

HTTP 会话管理

先说说 HTTP 协议，众所周知， 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 数据存储在客户端，这样