支持跨域访问，无状态认证
token特点
支持跨域访问:
Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输
无状态(也称：服务端可扩展行):
Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，
只需要在客户端的cookie或本地介质存储状态信息
更适用CDN:
可以通过内容分发网络请求你服务端的所有资料（如：javascript，html,图片等），而你的服务端只要提供API即可
去耦:
不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可
更适用于移动应用:
当你的客户端是一个原生平台（ios, android）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），
这时采用Token认证机制就会简单得多。
CSRF:
因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
token基本原理
Request指在一次请求的全过程中有效，即从http请求到服务器处理结束，返回响应的整个过程，存放在HttpServletRequest对象中。
Session是用户全局变量，在整个会话期间都有效。只要页面不关闭就一直有效（或者直到用户一直未活动导致会话过期，默认session过期时间为30分钟）
token 认证过程
客户端使用用户名跟密码请求登录
服务端收到请求，去验证用户名与密码
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
因为token是被签名的，所以我们可以认为一个可以解码认证通过的token是由我们系统发放的，其中带的信息是合法有效的
基于JWT的Token认证
JSON Web Token（JWT）是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。
JWT的组成：
一个JWT实际上就是一个字符串，它由三部分组成，头部、载荷与签名
头部（Header）
用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。
然后将其进行base64编码，得到第一部分
{
"typ": "JWT",
"alg": "HS256"
}
载荷（Payload）
一般添加用户的相关信息或其他业务需要的必要信息。但不建议添加敏感信息，因为该部分在客户端可解密
（base64是对称解密的，意味着该部分信息可以归类为明文信息）
然后将其进行base64编码，得到第二部分
{ "iss": "JWT Builder",
"iat": 1416797419,
"exp": 1448333419,
"aud": "www.example.com",
"sub": "aaa@example.com",
"Email": "aaa@example.com",
"Role": [ "admin", "user" ]
}
iss:
该JWT的签发者，是否使用是可选的；
sub:
该JWT所面向的用户，是否使用是可选的；
aud:
接收该JWT的一方，是否使用是可选的；
exp(expires):
什么时候过期，这里是一个Unix时间戳，是否使用是可选的；
iat(issued at):
在什么时候签发的(UNIX时间)，是否使用是可选的；
nbf (Not Before):
如果当前时间在nbf里的时间之前，则Token不被接受；是否使用是可选的；
jti:
JWT的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。
签名（Signature）
需要base64加密后的header和base64加密后的payload使用"."连接组成的字符串，
然后通过header中声明的加密方式进行加盐secret组合加密（在加密的时候，我们还需要提供一个密钥（secret），加盐secret组合加密）
然后就构成了jwt的第三部分。
最后，将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT
注意：secret就是你服务端的私钥，在任何场景都不应该流露出去。
一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了