JWT令牌

一、JWT（Json Web Token）能干什么

1、安全认证（权限认证）

比如登录系统的时候，服务器会检查前端请求数据中携带的token信息，符合标准则允许访问，不符合则拒绝你的访问请求。

2、信息传递

比如两个系统之间传递信息，a服务器向B服务器发送token信息，b服务器对token进行解签名，发现签名对的上就接收数据，对不上就拒绝a服务器发来的数据（访问）。

二、JWT组成

头（header）.负载（payload）.签名（signature）

头、负载、签名三个部分组成，并用点符号衔接。

头：放签名用的加密算法

负载：一些不敏感的用户信息，通过base64编码放在负载中

签名：头+负载+加密后的签名（也称密钥）

三、为什么要用Session或JWT认证机制？

因为HTTP是无状态的网络协议，比如，一套系统势必会存在很多次请求，而你的每一次请求服务器都不知道一个个请求是你发送的还是别人发送的，就会造成你已经登录成功进入页面搜索某个东西点击确认发送了一个搜索数据的请求，然而服务器已经不记得你是谁、是否登录成功，然后听都不听你的请求就被服务器关在门外了，因此你的每一次亲求都要进行一次身份验证，但总不能每发送一次请求都要输入一遍账户密码来验证你是具备请求权限的吧？所以你再一次登录请求成功的时候就给你发一张“通行证”，后面同一个系统内部的请求都带上这张“通行证”表示你在这个系统中有相应的权限，人后尽管说出你的请求，服务器看到你的“通行证”“心领神会”“理所当然”接受你的请求，然后根据你的请求在“能力范围内”响应你的请求。

三、Session和JWT认证机制的区别、优缺点

1、Session流程

客户端第一次向服务器发送请求验证身份，身份验证通过，服务器生成JSESSIONID，放在cookie身上响应给客户端浏览器，浏览器吧cookie保存在浏览器中，下次请求时，找到对应的cookie，放在请求头一并发送到服务器，服务器根据cookie信息验证身份，验证成功查看你的请求作出响应。

2、Session缺点

[1]每当一个用户第一次发送请求生成sessionid，sessionid就会被存储在服务器内存中，当请求用户增多，服务器开销随之变大；

[2]某一用户第一次发送请求，生成的sessionid存储后，该用户以后发送的每一次请求都只能到特定服务器中申请访问资源，不利于分布式负载均衡

[3]sessionid是通过cookie传送哎浏览器和服务器之间来回传送的，容易被跨站请求伪造攻击

[4]前后端分离项目，不易部署；同一个系统需要发送很多个请求，而session、cookie认证技术并没有减少每次都要进行搜索用户信息进行身份认证的动作

3、JWT认证流程

浏览器第一次向服务器发送请求的时候，服务器生成一个令牌，之后这个令牌不再保存在服务器中，而是在保存在客户的浏览器中，释放服务器的内存。往后客户只需要携带令牌请求数据就可以了，而且服务器只用判断令牌是否有效就行了。也就是说JWT中有客户信息，解码后获取用户信息直接验证权限，不用额外再去数据库查用户信息、比对来验证用户权限。另外token会被存在浏览器的sessionStorage或者local Storage中，当系统退出登录的时候token就会被删除释放浏览器内存。

另一番理解：header

cookie：将用户信息（如账号、角色信息，不包括密码等敏感信息）以明文 方式存储在浏览器中，服务器直接根据header携带的信息验证用户身份。相对于session缺乏安全性。

session：给一个id给cookie，服务器根据这个id查询数据库验证用户身份。相对安全。

JWT：将用户信息以base64编码（字符串）给cookie存储在用户浏览器，服务器获取header中的Authorization或URL或cookie中携带的token中的解码＋解签名之后的用户信息，进行用户验证。相对于session缺乏安全性。

4、JWT优势

[1]token本身就有用户信息。只需要解密就可以直接获得用户信息数据，而不用再取数据库查询数据了，简单的查询还好就怕复杂数据地查询。

[2]保存在用户浏览器中，释放服务器的部分内存压力

5、JWT缺点

[1]token在传输的过程中有被截获，被人拿去冒充用户请求内部数据的风险：

1、不安全的存储方式：一些开发人员可能会把token存储在local storage、cookie、URL参数等不安全的位置，容易被攻击者获取到。

2、使用http协议传输token：http协议是明文传输，攻击者可以通过中间人攻击截获token。

3、token窃取过程中的漏洞：部分应用程序没有对用户输入做充足的过滤和检查，攻击者可以通过在输入框中注入特定代码来盗取token

[2]一旦签发一个jwt，在到期之前就会始终有效，无法中途废弃。例如你在payload中存储了一些信息，当信息需要更新时，则重新签发一个jwt，但是由于旧的jwt还没过期，拿着这个旧的jwt依旧可以登录，那登录后服务端从jwt中拿到的信息就是过时的。为了解决这个问题，我们就需要在服务端部署额外的逻辑，例如设置一个黑名单，一旦签发了新的jwt，那么旧的就加入黑名单（比如存到redis里面），避免被再次使用。