为了更好的理解token就使用，token、session 、cookie三者进行比较
cookie：
cookie数据存放在客户的浏览器上;
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗;
适合保存一些不太重要的信息;
session:
session数据临时放在服务器上，至少这点安全性比cookie好;
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能;
web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失,也就是说刚刚才输入了帐号密码，可能又再次输入。
适合把帐号和加密的密码用session存储
token:
token用的最多场景就是用户输入帐号密码后，一段时间内就可以避免重复再次输入。
cookie和session都可以实现类似的功能但是都没token安全，cookie和session都需要发出加密后的密码，想象一样虽然密码都密码了但是被公布出来始终还是觉得不安全。使用token认证不需要直接去操作用户的帐号和密码。
作为身份认证 token安全性比session好，因为每个请求都有签名还能防止监听以及攻击。
//用token作为身份认证最常见的工作流程：(密码模式) 1. 登录时候,客户端通过用户名与密码请求登录。(用正确的帐号密码来跟服务器换一个token可以理解为令牌) 2. 服务端收到客户端发来的帐号密码，并去验证用户名与密码 3. 验证通过,服务端会签发一个Token,再把这个Token发给客户端. 4. 客户端收到Token,存储到本地,如Cookie,SessionStorage,LocalStorage(如果涉及到跨域建议用cookie来暂时存储token).我们是存在SessionStorage 5. 客户端每次像服务器请求API接口时候,都要带上Token,把token放入到Request Headers服务器那里就可以获取到。(带上的token其实就是从存储在本地的Cookie,SessionStorage,LocalStorage来获取到token) 6. 服务端收到请求,验证Token,如果通过就返回数据,否则提示报错信息.
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
headers的一些理解：https://sdeno.com/?p=6375
通过headers传参具体操作：https://sdeno.com/?p=6358
jquery的ajax传递header参数：
$.ajax({
beforeSend: function(xhr) { //请求服务器前先执行
xhr.setRequestHeader("Access-Toke");
},
headers: { //请求时，需要带的参数
'Access-Token':$.cookie('access_token')
},
url: url,
data: data
});
/—————————————————————————-
——————————————————————————/
了解JWT，并使用
认证成功后服务器一般会返回这么一些字符串类似于。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIyMzczIiwiaXNzIjoiaHR0cHM6Ly93d3ctcWEud2VpY2xpY2FpLmNvbS9hcGkvdmMvbG9naW4iL CJpYXQiOjE1MzI0MTg3MTUsImV4cCI6MTU2Mzk1NDcxNSwibmJmIjoxNTMyNDE4NzE1LCJqdGkiOiJvRm5LcEkxMkZ3cUk2aGt5In0.rDagPOmG_IZ6p9zbAHo BMNW0S56q30ScT-aug4l51rI
以上这些字符串就是token值，也就是JWT。
JWT适用于情景：
1，需要认证用户。例如：需要账户和密码
2，可能会存在跨域认证的问题。
如果遇上以上两种问题，使用JWT是最佳的解决方案。
JWT 的数据结构：
eyxxxxxxx.eyxxxxxx.xxxxxxxx
它是一个很长的字符串，中间用点（.）分隔成三个部分。
这三部分，分别是：
Header（头部）.Payload（负载）.Signature（签名）
Header介绍
Header 部分是一个 JSON 对象，通常是下面的样子。
{
"alg": "HS256",
"typ": "JWT"
}
上面代码中，alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）；typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。
最后，将上面的 JSON 对象使用 Base64URL 算法（详见后文）转成字符串。
Payload介绍
Payload 部分也是一个 JSON 对象，参数都是可选
{
iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号
}
例子：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。
这个 JSON 对象也要使用 Base64URL 算法转成字符串。
Signature介绍
Signature 作用是对前两部分的签名，防止数据篡改，但前提需要一个密钥（secret），这个密钥只有服务器才知道，不能泄露给用户。
。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。
就这样JWT的结果就是由以下公式得出：
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Base64URL
前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。
JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里
面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。
最后,如何使用JWT
既要有认证功能又要有跨域功能，最后的方法就是，放在 HTTP 请求的头信息Authorization字段里面。
Authorization: Bearer eyxxxxxxx.eyxxxxxx.xxxxxxxx
另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。
JWT 优缺点
（1）JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
（2）JWT 不加密的情况下，不能将秘密数据写入 JWT。
（3）JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
（4）JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
（5）JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
（6）为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。
http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html