JWT(JSON WEB Token)

转载了：https://www.jianshu.com/p/792f71bb52dd

https://blog.csdn.net/weixin_37569048/article/details/80118059

• 在Web应用中，使用JWT替代session并不是个好主意
• 适合JWT的使用场景

使用JWT管理session还有如下缺点：

1. 更多的空间占用。如果将原存在服务端session中的各类信息都放在JWT中保存在客户端，可能造成JWT占用的空间变大，需要考虑cookie的空间限制等因素，如果放在Local Storage，则可能受到XSS攻击。

2. 更不安全。这里是特指将JWT保存在Local Storage中，然后使用Javascript取出后作为HTTP header发送给服务端的方案。在Local Storage中保存敏感信息并不安全，容易受到跨站脚本攻击，跨站脚本（Cross site script，简称xss）是一种“HTML注入”，由于攻击的脚本多数时候是跨域的，所以称之为“跨域脚本”，这些脚本代码可以盗取cookie或是Local Storage中的数据。可以从这篇文章查看XSS攻击的原理解释。

3. 无法作废已颁布的令牌。所有的认证信息都在JWT中，由于在服务端没有状态，即使你知道了某个JWT被盗取了，你也没有办法将其作废。在JWT过期之前（你绝对应该设置过期时间），你无能为力。

4. 不易应对数据过期。与上一条类似，JWT有点类似缓存，由于无法作废已颁布的令牌，在其过期前，你只能忍受“过期”的数据。

那究竟JWT可以用来做什么?

JWT（其实还有SAML）最适合的应用场景就是一次性验证,“开票”，或者“签字”。

在有纸化办公时代，多部门、多组织之间的协同工作往往会需要拿着A部门领导的“签字”或者“盖章”去B部门“使用”或者“访问”对应的资源，其实这种“领导签字／盖章”就是JWT，都是一种由具有一定权力的实体“签发”并“授权”的“票据”。一般的，这种票据具有可验证性（领导签名／盖章可以被验证，且难于模仿），不可篡改性（涂改过的文件不被接受，除非在涂改处再次签字确认）；并且这种票据一般都是“一次性”使用的，在访问到对应的资源后，该票据一般会被资源持有方收回留底，用于后续的审计、追溯等用途。

例子：

1. 员工李雷需要请假一天，于是填写请假申请单，李雷在获得其主管部门领导签字后，将请假单交给HR部门韩梅梅，韩梅梅确认领导签字无误后，将请假单收回，并在公司考勤表中做相应记录。
2. 员工李雷和韩梅梅因工外出需要使用公司汽车一天，于是填写用车申请单，签字后李雷将申请单交给车队司机老王，乘坐老王驾驶的车辆外出办事，同时老王将用车申请单收回并存档。
3. 用户注册后需要发一封邮件让其激活账户，通常邮件中需要有一个链接，这个链接需要具备以下的特性：能够标识用户，该链接具有时效性（通常只允许几小时之内激活），不能被篡改以激活其他可能的账户。这种场景就和 jwt 的特性非常贴近，jwt 的 payload 中固定的参数：iss 签发者和 exp 过期时间正是为其做准备的。

在以上的两个例子中，“请假申请单”和“用车申请单”就是JWT中的payload，领导签字就是base64后的数字签名，领导是issuer，“HR部门的韩梅梅”和“司机老王”即为JWT的audience，audience需要验证领导签名是否合法，验证合法后根据payload中请求的资源给予相应的权限，同时将JWT收回。

放到系统集成的场景中，JWT更适合一次性操作的认证:

服务B你好, 服务A告诉我，我可以操作<JWT内容>, 这是我的凭证（即JWT）

在这里，服务A负责认证用户身份（相当于上例中领导批准请假），并颁布一个很短过期时间的JWT给浏览器（相当于上例中的请假单），浏览器（相当于上例中的请假员工）在向服务B的请求中带上该JWT，则服务B（相当于上例中的HR员工）可以通过验证该JWT来判断用户是否有权执行该操作。这样，服务B就成为一个安全的无状态的服务了。

总结

1. 在Web应用中，别再把JWT当做session使用，绝大多数情况下，传统的cookie-session机制工作得更好
2. JWT适合一次性的命令认证，颁发一个有效期极短的JWT，即使暴露了危险也很小，由于每次操作都会生成新的JWT，因此也没必要保存JWT，真正实现无状态。

JWT(JSON WEB Token)

原文：https://www.cnblogs.com/wangxiaofengde/p/12040874.html