一、JWT基础
概念：JWT(JSON WEB TOKEN) 是一个开放标准（RFC 7519），它定义了一种紧凑、自包含的方式，用于作为JSON对象在各方之间安全的传输信息。该信息可以被验证和信任，因为它是数字签名
场景：
Authorization(授权)：使用JWT最常见的场景，一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。
Information exchange(信息交换)： 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。
二、JWT结构
Json Web Token由三部分组成，Header（头部）、Payload(声明)、Signature(签名)，它们之间用圆点(.)连接，例如xxxxx.yyyyyy.zzzzz
Header：header典型的由两部分组成：token类型（“JWT”）和算法名称(比如：HMAC SHA256或者RSA等等)
{ "typ":"JWT", "alg":""RSA", }
Payload：包含声明（要求），自定义的用户信息，根据需求制定。比如用户名、权限等等
{ "name":"levi", "permission":["USER_ADD","USER_DELETE","USER_SEARCH"] }
Signature：验证消息在传递过程中有没有被更改
三、JWT工作流程
在用户用他们的凭证登录认证成功以后，生成一个JWT返回。此后，token就是用户凭证了，必须非常小心防止出现安全问题（token泄露）。一般而言，保存令牌的时候不应该超过你所需要它的时间。
无论何时用户想要访问受保护的路由或者资源的时候，用户代理（通常是浏览器）都应该带上JWT，典型的，通常放在Authorization header中，用Bearer schema。
- 应用（或者客户端）想授权服务器请求授权。例如，如果用授权码流程的话，就是/oauth/authorize
- 当授权被许可以后，授权服务器返回一个access token给应用
- 应用使用access token访问受保护的资源（比如：API）
四、基于 Token 的身份认证 与 基于服务器的身份认证
1、基于服务器的身份认证
传统的做法是将已经认证过的用户信息存储在服务器上，比如Session。用户下次请求的时候带着Session ID，然后服务器以此检查用户是否认证过。
存在如下问题：
a、session存储内存，用户过多，消耗内存
b、session共享问题
c、跨域请求授权问题
d、容易遭受CSRF攻击
2、JWT 与 session 的差异
a、session 存储在服务器，JWT保存在客户端，JWT更利于减轻服务端内存压力
b、JWT是无状态的，可以解决 用户信息 共享问题
c、JWT是加密字符串，更加安全，有助于防止CSRF攻击
3、JWT 与 OAuth 的区别
a、OAuth2 是一种授权框架，JWT 是一种认证协议
b、无论使用哪种方式切记用HTTPS来保证数据的安全性