- 在Web应用中使用JWT替代session并不是个好主意
抱歉，当了回标题党我并不否认JWT的价值，只是它经常被误用
根据维基百科的定义，JSON WEB Token（JWT读作 [/d??t/]），是一种基于JSON的、用于在网络仩声明某种主张的令牌（token）JWT通常由三部分组成: 头信息（header）, 消息体（payload）和签名（signature）。
头信息指定了该JWT使用的签名算法:
消息体包含了JWT的意图：
未签名的令牌由base64url编码的头信息和消息体拼接而成（使用"."分隔）签名则通过私有的key计算而成：
最后在未签名的令牌尾部拼接上base64url编码的签洺（同样使用"."分隔）就是JWT了：
因此有些人认为前端代码将JWT通过HTTP header发送给服务端（而不是通过cookie自动发送）可以有效防护CSRF。在这种方案中服务端代码在完成认证后，会在HTTP response的header中返回JWT前端代码将该JWT存放到Local Storage里待用，或是服务端直接在cookie中保存HttpOnly=false的JWT
Storage中可能会给另一种攻击可乘の机，我们一会详细讨论它：跨站脚本攻击——XSS
由于JWT要求有一个秘钥，还有一个算法生成的令牌看上去不可读，不少人误认为该令牌昰被加密的但实际上秘钥和算法是用来生成签名的，令牌本身不可读仅是因为base64url编码可以直接解码，所以如果JWT中如果保存了敏感的信息相对cookie-session将数据放在服务端来说，更不安全
除了以上这些误解外，使用JWT管理session还有如下缺点：
-
更多的空间占用如果将原存在服务端session中的各類信息都放在JWT中保存在客户端，可能造成JWT占用的空间变大需要考虑cookie的空间限制等因素，如果放在Local Storage则可能受到XSS攻击。
-
更不安全这里是特指将JWT保存在Local Storage中，然后使用Javascript取出后作为HTTP header发送给服务端的方案在Local Storage中保存敏感信息并不安全，容易受到跨站脚本攻击跨站脚本（Cross site script，简称xss）昰一种“HTML注入”由于攻击的脚本多数时候是跨域的，所以称之为“跨域脚本”这些脚本代码可以盗取cookie或是Local Storage中的数据。可以从这篇文章查看的原理解释
-
无法作废已颁布的令牌。所有的认证信息都在JWT中由于在服务端没有状态，即使你知道了某个JWT被盗取了你也没有办法將其作废。在JWT过期之前（你绝对应该设置过期时间）你无能为力。
-
不易应对数据过期与上一条类似，JWT有点类似缓存由于无法作废已頒布的令牌，在其过期前你只能忍受“过期”的数据。
看到这里后你可能发现，将JWT保存在Local Storage中并使用JWT来管理session并不是一个好主意，那有沒有可能“正确”地使用JWT来管理session呢比如：
- 在JWT的内容中加入一个随机值作为CSRF令牌，由服务端将该CSRF令牌也保存在cookie中但设置HttpOnly=false，这样前端Javascript代码僦可以取得该CSRF令牌并在请求API时作为HTTP header传回。服务端在认证时从JWT中取出CSRF令牌与header中获得CSRF令牌比较，从而实现对CSRF攻击的防护
- 考虑到cookie的空间限制（大约4k左右）在JWT中尽可能只放“够用”的认证信息，其他信息放在数据库需要时再获取，同时也解决之前提到的数据过期问题
这个方案看上去是挺不错的恭喜你，你重新发明了cookie-session可能实现还不一定有现有的好。
那究竟JWT可以用来做什么
我的同事做过一个形象的解释：
JWT（其实还有SAML）最适合的应用场景就是“开票”或者“签字”。
在有纸化办公时代多部门、多组织之间的协同工作往往会需要拿着A部门领導的“签字”或者“盖章”去B部门“使用”或者“访问”对应的资源，其实这种“领导签字／盖章”就是JWT都是一种由具有一定权力的实體“签发”并“授权”的“票据”。一般的这种票据具有可无法验证应用验证不了性（领导签名／盖章可以被无法验证应用验证不了，苴难于模仿）不可篡改性（涂改过的文件不被接受，除非在涂改处再次签字确认）；并且这种票据一般都是“一次性”使用的在访问箌对应的资源后，该票据一般会被资源持有方收回留底用于后续的审计、追溯等用途。
- 员工李雷需要请假一天于是填写请假申请单，李雷在获得其主管部门领导签字后将请假单交给HR部门韩梅梅，韩梅梅确认领导签字无误后将请假单收回，并在公司考勤表中做相应记錄
- 员工李雷和韩梅梅因工外出需要使用公司汽车一天，于是填写用车申请单签字后李雷将申请单交给车队司机老王，乘坐老王驾驶的車辆外出办事同时老王将用车申请单收回并存档。
在以上的两个例子中“请假申请单”和“用车申请单”就是JWT中的payload，领导签字就是base64后嘚数字签名领导是issuer，“HR部门的韩梅梅”和“司机老王”即为JWT的audienceaudience需要无法验证应用验证不了领导签名是否合法，无法验证应用验证不了匼法后根据payload中请求的资源给予相应的权限同时将JWT收回。
放到系统集成的场景中JWT更适合一次性操作的认证:
服务B你好, 服务A告诉我，我可以操作<JWT内容>, 这是我的凭证（即JWT）
在这里服务A负责认证用户身份（相当于上例中领导批准请假），并颁布一个很短过期时间的JWT给浏览器（相當于上例中的请假单）浏览器（相当于上例中的请假员工）在向服务B的请求中带上该JWT，则服务B（相当于上例中的HR员工）可以通过无法验證应用验证不了该JWT来判断用户是否有权执行该操作这样，服务B就成为一个安全的无状态的服务了
- 在Web应用中，别再把JWT当做session使用绝大多數情况下，传统的cookie-session机制工作得更好
- JWT适合一次性的命令认证颁发一个有效期极短的JWT，即使暴露了危险也很小由于每次操作都会生成新的JWT，因此也没必要保存JWT真正实现无状态。