关于JWT，它是基于json数据结构的认证规范，简单来说就是验证用户登录状态，跟之前的session很类似，那么，在有些时候我们为什么用JWT而不用session呢？
首先我们要了解一下HTTP：
http协议本身是一种无状态的协议，这就意味着每次请求API的时候，
都会把用户名和密码传给服务端，当我们通过http请求发送给服务端的时候，很有可能将我们的用户名密码直接暴露给第三方客户端，风险非常大，因此生产环境下很少用这个方法
session和cookie
这个我们就比较熟悉了，大概的流程就是 用户第一次访问服务器会携带用户的登录
信息，然后服务端创建session对象，session对象保存着各种关键信息，同时向客户端发送一组sessionid,成为一个cookie对象保存在浏览器中， 当认证是，cookie的数据会传入服务端与session进行匹配来进行数据认证。
此时，session实现的就是一个有状态的思想，即改服务的实例可以将一部分数据随时进行备份，并且创建一个新的状态服务是通过备份恢复这些数据，达到数据持久化。
缺点：
安全性：首先是cookies的安全性并不是很好，攻击者可以截获cookies进行CSRF攻击；
跨域问题：使用cookies是，如果在多个域名下，就会存在跨域问题
有状态： session在一定时间里，需要存放在服务端，因此项目上线之后，如果大量用户同时访问，需要实现状态保持，就会大幅度降低服务端的性能。
状态问题： 当我们的项目有多个服务器的时候，如何共享session也是一个问题，如果用户第一个访问的服务器是A，而第二个请求被转发到了服务器B，B根本无法得知其状态。
移动端APP： 手机端并不支持原生cookie，使用会非常麻烦
Token认证
我们这的token是指 访问资源的凭据，使用基于token的身份认证方法，在
服务端不需要存储用户的登录记录，大概的流程是这样：
1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务器端会签发一个Token，再把这个Token发送给客户端
4. 客户端收到Token后把它存储起来，比如放在cookie中
5. 客户端每次向服务器发送请求时需要携带这个token
6. 服务器收到请求，然后去验证客户端请求里面带着的token，如果验证成功，就向客户端返回请求的数据
我认为这个Token机制就是加强的session，使其更加简便安全。
那么我们具体来说一下它的好处：
1. 支持跨域访问： 只要你传输的用户认证信息通过HTTP的headers尽心传输
2. 无状态： Token机制本质是校验，它得到的回话状态完全来自于客户端，token机制在服务端不需要存储session信息，因为它自身就包含了所有登录用户的信息。
3. 更实用CDN:可以通过内容分发网络请求你的服务端的所有资料（如：
JavaScript， HTML， 图片），而你的服务端只需提供API
4. 去耦：不需要绑定到一个特定的身份验证方案，只需对身份信息进行加密
5. 性能: 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256 计算 的Token验证和解析要费时得多.不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候，不再需要 为登录页面做特殊处理.
6. 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在 多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如： Firebase,Google, Microsoft）
说了这么多Token认证的好处，但它也有不少的缺点：
1.占带宽：正常情况下要比 session_id 更大，需要消耗更多流量，挤占更多带宽，假如你的网站每月有 10 万次的浏览器，就意味着要多开销几十兆的流量。听起来并不多，但日积月累也是不小一笔开销。实际上，许多人会在 JWT 中存储的信息会更多。
2. 无法在服务端注销，那么久很难解决劫持问题
3. 性能问题：
JWT 的卖点之一就是加密签名，由于这个特性，接收方得以验证 JWT 是否有效且被信任。但是大多数 Web 身份认证应用中，JWT 都会被存储到 Cookie 中，这就是说你有了两个层面的签名。听着似乎很牛逼，但是没有任何优势，为此，你需要花费两倍的 CPU 开销来验证签名。对于有着严格性能要求的 Web 应用，这并不理想，尤其对于单线程环境。
JWT的构成
第一部分我们称它为头部（header),第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)，第三部分是签证（signature).
header
jwt的头部承载两部分信息：
声明类型，这里是jwt
声明加密的算法 通常直接使用 HMAC SHA256
完整的头部就像下面这样的JSON：
{
‘typ’: ‘JWT’,
‘alg’: ‘HS256’
}
然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
payload
载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分
标准中注册的声明
公共的声明
私有的声明
标准中注册的声明 (建议但不强制使用) ：
iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间，这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。
公共的声明 ： 公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.
私有的声明 ： 私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。
定义一个payload:
{
“sub”: “1234567890”,
“name”: “John Doe”,
“admin”: true
}
然后将其进行base64加密，得到JWT的第二部分。
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
signature
JWT的第三部分是一个签证信息，这个签证信息由三部分组成：
header (base64后的)
payload (base64后的)
secret
这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。
// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);
var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
将这三部分用.连接成一个完整的字符串,构成了最终的jwt:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。