token 与 基于JWT的Token认证

支持跨域访问，无状态认证

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了