What is the JWT
JWT a look that is short, it's full name Web Token JSON , we literally see
1, data JSON format
2 for Web applications
3, the Token is a, a token is a
Look at the official explanation, it defines a compact and self-contained way, for between the parties to conduct secure transmission of information JSON object . This information can be symmetric / asymmetric manner be signed to prevent tampering information .
Compact meanings: is JWT relatively small, the amount of data , by URL, POST parameters, or Header request header to be transmitted in.
The meaning of self-contained: jwt allows users to customize the user JWT information contained inside , such as: name, nickname, etc. ( do not put secret information ). Thereby avoiding multiple database queries .
JWT data structure
JWT three components
1、Header
2、Payload
3、Signature
Three together
Header.Payload.Signature
Case
Appears to be not full of chaos, we turn to look at the inside of the structure.
Header
This is JWT first segment data indicating header information , the main role is to describe JWT metadata , the above case is:
{
alg: "HS256", typ: "JWT" } 1, alg property indicates the signature algorithm, the default algorithm HS256 , free to other algorithms.
2, typ attribute indicates the type of the token , JWT token on to JWT.
The above data is JSON by Base64 algorithm encodes formed, see FIG tool
Payload
This is the second portion of data JWT, used to store the actual data transfer is required. JWT official also provides for the selection of the seven fields
Of course, in addition to the official field, we can customize the fields to the above case, we look at the actual data
Note: This is a Base64 algorithm, JWT default is not encrypted , anyone can get, as long as Base64 decoding on the line, so do not put secret information into the JWT
Signature
This is the third paragraph JWT data, the main role is data preceding two paragraphs are signed to prevent tampering . Generally when we sign will have a key (Secret) , only the server knows , then use Header signature algorithms to sign the following formula:
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret)
After calculating the signature, the Header, Payload, Signature makes up a string of three parts , with between (.) Separated, so that the string can be a combination of a return to the user.
JWT works
在用户进行认证登录时，登录成功后服务器会返回一个JWT给客户端；那这个JWT就是用户的凭证，以后到哪里去都要带上这个凭证token。尤其访问受保护的资源的时候，通常把JWT放在Authorization header中。要用 Bearer schema，如header请求头中：
Authorization: Bearer <token>
基于JWT的身份认证
上面的JWT的工作方式，其实就是一个完整的身份认证流程，我们这里把这个讲的在通俗一点。
1、用户提供用户名和密码登录
2、服务器校验用户是否正确，如正确，就返回token给客户端，此token可以包含用户信息
3、客户端存储token，可以保存在cookie或者local storage
4、客户端以后请求时，都要带上这个token，一般放在请求头中
5、服务器判断是否存在token，并且解码后就可以知道是哪个用户
6、服务器这样就可以返回该用户的相关信息了
这个流程小伙伴们有没有发现，用户信息是放在JWT中的，是存放在客户端（cookie，local storage）中的，服务器只需解码验证就行了，就可以知道获取到用户信息。而我们之前的Session方式就不一样。
与Session-Cookie方式的区别
Session-Cookie方式的这里就不多作介绍了，之前文章已经介绍了。直接上图说明区别
上图是Sesson服务器方式，我们发现Session用户信息是在服务器端存储的。
我们再来看看JWT方式
上面的token即用户信息是存储在客户端的，服务器端只要解码即可。
JWT方式认证的好处
1、因为token存储在客户端，服务器只负责解码。这样不需要占用服务器端资源。
2、服务器端可以无限扩展，负载均衡器可以将用户传递到任何服务器，服务器都能知道用户信息，因为jwt里面包含了。
3、数据安全，因为有签名，防止了篡改，但信息还是透明的，不要放敏感信息。
4、放入请求头提交，很好的防止了csrf攻击，
说了这么多的好处，那是不是JWT就非常适合替换掉Session方式呢？
JWT方式的坏处
一、token失效问题
JWT方式最大的坏处就是无法主动让token失效，小伙伴们会说token不是有过期时间吗？是的，token本身是有过期时间，但token一旦发出，服务器就无法收回。
如：一个jwt的token的失效时间是3天，但我们发现这个token有异常，有可能被人登录，那真实的用户可以修改密码。但是即使修改了密码，那个异常的token还是合法的，因为3天的失效时间未到，我们服务器是没法主动让异常token失效。
二、数据延时，不一致问题
还有个问题就是因为jwt中包含了用户的部分信息，如果这些部分信息修改了，服务器获取的还是以前的jwt中的用户信息，导致数据不一致。
总结
小伙伴们怎么去选择Session的方式，是用传统的Sesion-Cookie服务器方式，还是用JWT方式，具体集合业务看。不过老顾这里推荐还是用传统的方式，因为以后的业务很有可能会用到用户Session。好了，谢谢！！！