一、Session的认证
该方案的特点：
登录用户信息保存在服务端内存中，若访问量增加，单台节点压力会较大。
随用户规模增大，若后台升级为集群，则需要解决集群中各服务器登录状态共享的问题。
二、JWT详解
1、JWT概述
JWT（JSON Web TOKEN）是一种轻量级的安全传输方式，用于在两个实体之间传递信息，通常用于身份验证和信息传递。
通俗地说,JWT的本质就是一个保存了用户信息的Json字符串，然后进行编码后得到一个JWT token,并且这个JWT token带有签名信息,接收后可以校验是否被篡改，所以可以用于在各方之间安全地将信息作为Json对象传输。
JWT优点：
- 简洁：JWT Token数据量小，传输速度也很快。
- JWT是跨语言的：因为JWT Token是以JSON加密形式保存在客户端的，所以，原则上任何web形式都支持。
- 不依赖于cookie和session， 不需要在服务端保存会话信息,特别适用于分布式微服务。
- 既然不依赖于cookie和session，可以将token缓存到redis等，就不需要考虑session多服务节点的同步问题，及cookie无法跨域的问题,更适用与单点登录, 移动端。
2、JWT组成
JWT由3部分组成：Header标头,Payload有效载荷和Signature签名,，在传输的时候,将这3部分分别进行Base64编码后连接形成最终传输的字符串。
1、标头
JWT Header标头，是用来描述JWT元数据的JSON对象,包含alg属性与typ属性，其中alg表示签名使用的算法，默认为HMAC SHA256(写为HS256)，typ属性表示令牌的类型，在JWT令牌统一写为JWT，然后使用Base64URL算法将上述这个JSON对象转换为字符串保存，例如：
{
"alg": "HS256",
"typ": "JWT"
}
2、有效载荷
Payload有效载荷是JWT的主体内容部分,也是一个JSON对象，包含需要传递的数据，在JWT中默认有一下七个字段供选择，这七个预定义字段并不要求强制使用，并且除以上默认字段外，我们还可以自定义私有字段，例如将包含用户信息的数据放到payload中：
//1.Payload有效载荷默认提供的七个预定义字段,不要求强制使用
- iss：发行人
- exp：到期时间
- sub：主题
- aud：用户
- nbf：在此之前不可用
- iat：发布时间
- jti：JWT ID用于标识该JWT
//2.除了预定义的七个字段以外,我们也可以自定义Payload有效载荷字段,例如将包含用户信息的数据放到payload中
{
"sub": "1234567890",
"name": "Helen",
"admin": true
}注意点：默认情况下JWT只是采用base64算法进行了一次编码，并未加密的，拿到JWT字符串后可以转换回原本的JSON数据，因此不要构建隐私信息字段，比如用户的密码不要保存到JWT中，以防止信息泄露,默认情况下JWT只适合在网络中传输一些非敏感信息。
3、签名
Signature签名用来校验数据是否被篡改的，将base64UrlEncode编码后的header和payload两个数据进行拼接后，通过指定的算法与密钥secret进行加密后的一串哈码，并且secret密钥保存在服务器中不对外公开，默认加密算法HMACSHA256()，Signature签名生成公式示例：
HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)
根据JWT Token中是否存在Signature签名又将JWT分为两类：
- 不使用Signature签名的JWT称为nonsecure JWT未经过签名,不安全的JWT，其header部分也没有指定签名算法。
- 使用了Signature签名的通过签名保证jwt不能被他人随意篡改,我们又称为JWS。
在生成Signature签名时提到了一个secret或secretKey密钥，JWT的密钥或者密钥对，一般统一称为JSON Web Key，也就是JWK，根据对称加密与非对称加密,密钥的使用也有所不同。
- 对称加密中：secretKey指加密密钥,用来生成签名与验签。
- 非对称加密中：secretKey指私钥,只用来生成签名,但是不能用来验签(验签用的是公钥)。
- 对称加密中使用同一个密钥进行加密与解密，因此这时候公钥不能泄漏，因此对称算法只适合服务端内部使用,不适合网络第三方，非对称加密通常服务端有私钥和公钥，使用私钥加密，使用公钥可以解密,相对来说更安全。
JWT中签名算法有三种：
- HMAC【哈希消息验证码(对称)】：HS256/HS384/HS512
- RSASSA【RSA签名算法(非对称)】（RS256/RS384/RS512）
- ECDSA【椭圆曲线数据签名算法(非对称)】（ES256/ES384/ES512）
4、完整的执行逻辑
- 接收到JWT Token数据后，获取header和payload通过base64解码获取到原数据，在header的alg属性中拿到签名的算法，在payload中获取有效数据。
- signature是对header和payload数据的加密无法解码出原文，用来校验整个token数据是否被篡改。
- 服务端在header中获取到加密算法后，利用该算法加上secret密钥对header，payload两个数据再次进行加密，拿到加密结果后与客户端发送过来的signature进行比对判断是否一致。
- 注意secret密钥只保存在服务端，而且对于不同的加密算法其含义有所不同，对于MD5类型的摘要加密算法来说secret密钥代表的是盐值。
三、Token认证
该方案的特点：
登录状态保存在客户端，服务器没有存储开销。
客户端发起的每个请求自身均携带登录状态，所以即使后台为集群，也不会面临登录状态共享的问题。
