目的：解决用户登录状态
从一个简单的登录开始说起，
在我们访问bilibili的时候，第一次需要登录，但后续就不需要登录了，可以直接访问bilibili。
而且每次在页面请求服务器的资源都需要维持登录状态，如果没有使用任何一种技术(cookie,session,token),则需要我们每次请求的时候，都需要将账号密码包含在请求中，这种方式，既不安全，也很麻烦。
那有没有什么好的解决办法呢？
这时候cookie出现了，cookie在客户端-服务器之间的流程如下：
也就是使用了cookie后，用户在第一次成功登录后，服务器会将用户的信息响应到客户端中，客户端(浏览器)会将用户信息保存到cookie中，也就是在客户端中保存了用户信息。那么在之后的每次访问服务器过程中，客户端(浏览器)会自动将cookie的内容包含在请求头(request header)中，如此便维持了用户的登录状态。
但这种方式会有很多的问题：
不安全，用户信息存储在客户端，客户可以修改信息
容量有限，默认4kb
用户可以禁用cookie
于是，session技术出来了，不同于cookie把内容存储在客户端，session把内容信息存储在服务器端。
在用户成功登录后，服务器会生成一个sessionID，并将sessionID响应到客户端中，客户端自动将sessionID保存在浏览器的cookie中。
后续用户的访问，也会自动将sessionID包含在请求头中，服务器判断sessionID是否存在，存在则表明用户已登录，即维持登录状态。而且整个过程是自动完成的，程序员只需要往session中存数据即可，使用起来十分方便。
同样，session优缺点如下：
优点：
安全性高，相比较cookie将用户信息存储在客户端，session将用户信息存储在服务器端，因此安全性较高
容量大，可以保存对象
缺点：
占用服务器资源，由于session容量大，因此在高并发过程中十分占用服务器资源
扩展性差
跨域限制
在分布式场景中，会有多台服务器，用户登录会在其中一台服务器中生成sessionID，而其他服务器没有sessionID，如果用户的下一次请求被分发到其他服务器中，则会误判用户没有登录。
而且在目前后端分离的大环境中，会有多个前端(web，小程序，h5，安卓端，ios端)，每个端都会有各自的域名端口，这个时候，前端请求后端会有跨域，跨域情况下，cookie默认是无法传递的，而sessionID本质上还是使用了cookie，也会被限制。因此需要前端单独去设置cookie允许跨域传递。
因此，在前后端的背景下，session也不再适用，于是token技术出现了。
token其实就是一个字符串，而JWT(Json Web Token)对token进行了一个规范。
Jwt由以点(.)分隔的三个部分组成，它们是：
Header
Payload
Signature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
其形式为xxxx.xxxx.xxxx
并且可以将其解析为三个部分
Header 由Token的类型(JWT)和所使用的签名算法(HMAC SHA265)组成
Payload为有效负载，其中包含你要放的数据内容。
Signature，这部分是一个签名，是对Header和Payload数据签名，确保上面的内容不被篡改。
JWT的认证流程：
用户在登录成功后，服务器会生成一个JWT，然后将token响应到客户端，存放到request header中，之后的每次请求会带上token，服务器接收到token会解密，检查signature是否被篡改。
优点：
适用于前后端分离场景和分布式项目
解决了session和coookie面临的跨域和存储压力问题
缺点：
JWT默认不加密，因此会导致数据泄密，但可以将原始令牌加密，来传输私密信息。