授权机制，当我们说到这个问题的时候，大家对它的第一印象是在哪个地方呢？是不是曾经某培训机构教授的 SSO 单点登录的，是的没错，而这种 SSO 的单点登录在当年的培训机构中，使用的就是 Session 共享，也就是用 Redis 做中间模拟 Session ，但是授权机制真的有这么简单么？接下来阿粉就来强势对比一下关于授权机制了。
Cookie-Session 认证授权
Cookie-Session 认证机制就是为一次请求认证在服务端创建一个Session对象，同时在客户端的浏览器端创建了一个Cookie对象；通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。
但是这时候我们就得考虑一下 Cookie 的存活时间了，当我们关闭浏览器的时候，Cookie就会被删除，就算我们调整了 Cookie 的存活时间，但是他依然有很大的弊端，Cookie 是很容易被拦截到的，阿粉之前就看到过某个知名的 OA 系统，就曾经把用户的ID 放到了 Cookie 中，只不过是把 Cookie 里面的键给设置成了 imageUrl，但是实际上这种，看着有点搞人的意思，图片地址是一堆长的字符串，你在前端拦截到之后， 明眼人一眼就能知道这种肯定不是图片路径，而且当我们使用 Cookie 进行用户识别,用户就会很容易受到跨站请求伪造的攻击,也就是我们经常说的 CSRF .
JWT
既然在这里对比 JWT ,我们就得先知道 JWT 是个什么东西，JSON Web Token (JWT) 实际上用大白话说，它就是一种认证机制，让后台知道请求是来自于受信的客户端。
技术都是随着问题出现的，只要有问题，那么很快就会有解决这个问题的技术出现，同样，JWT 出现的只不过比较早而已，因为现在微服务，分布式横行遍布，不管是大公司，还是小公司，很多都开始做分布式的项目，这做分布式也不仅仅是停留在了只存在大公司了，既然选择使用了分布式，那么各种各样的问题就来了。
- 跨域身份验证
- 分布式session共享
- 分布式站点的单点登录
JWT 是个什么玩意
我们先看一下官方网站给的内容，What is JSON Web Token?
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA
JSON Web令牌（JWT）是一种开放标准（RFC7519），它定义了一种紧凑且独立的方式，用于在各方之间安全地作为JSON对象传输信息。由于该信息是数字签名的，因此可以验证和信任此信息。可以使用秘密（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对对对对JWTs进行签名.
阿粉就直接用百度翻译了，结果翻译出来竟然差不多，看来百度翻译有时候也没有那么差劲。
那么什么时候需要去使用 JWT 呢？
在官网中，给出了两种情况下去使用 JWT ，Authorization 和 Information Exchange,一种是授权，授权我们都懂，就是当用户登录后，每个后续请求都将包括JWT，允许用户访问该令牌允许的路由、服务和资源,而资源交换，实际上简单的说，就是在数据传输中用 JWT 令牌在安全地在各方之间传输信息
那么我们既然知道了什么时候来使用 JWT, 我们就来看看 JWT 到底是长成什么样子，
JWT 构成：
- Header 头部
- Payload 有效载荷
- Signature 签名
我们从官网上获取了一段的内容，然后逐个来看，
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
既然它说 JWT 是由三段信息构成的，而这三段信息，是用 .来进行隔开的，也就是上面这长串的字符串，
Header 头部，我们看到图里面也给出了，Header 中存储的实际上就是2部分的内容。typ：类型 alg：加密算法，
然后他是对头部进行的 Base64 加密，我就是我们在官网摘下来的第一段的内容，就出现了加密字符串 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 。
Payload 有效载荷
实际上有效载荷实际上就是存储有效信息的地方，那么他都存储了一些什么内容呢？
- iss (issuer)：签发人
- exp (expiration time)：过期时间
- sub (subject)：主题
- aud (audience)：受众
- nbf (Not Before)：生效时间
- iat (Issued At)：签发时间
- jti (JWT ID)：编号( jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击)
为什么会有这么多，因为在 JWT 的规范中，他告诉我们的是，建议但不强制使用，也就是说，你可以根据自身的应用去选择使用，比如官网给出的，他就没有写全面，就使用了三个：
{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }
而实际上这部分的内容却是比较重要的内容。
signature签名信息
实际上这个就是一个组装起来的，将头部和载荷用’.'号连接，再加上一串密钥，经过头部声明的加密算法加密后得到签名。
这个 Header 和 Payload 都是加密过的，而在这个地方它还进行了 “加盐” 的操作，将这三部分用.连接成一个完整的字符串,构成了最终的jwt
jwt其实并不是什么高深莫测的技术，在很多技术人的眼中，可能觉得他会非常的low ，实际上虽然不高端，但是也没有那么 low，认证服务器通过对称或非对称的加密方式利用payload生成signature，并在header中申明签名方式，这就是 JWT 的本质实现方式。
JWT 的有点其实很明显，
- 通过验证签名的方式可以直接在资源服务器本地完成授权校验
- 在payload中可以包含用户相关信息，实现了token和用户信息的绑定
使用场景一般是用在一次性的身份验证上，千万不要想着去用 JWT 去代替 Session，虽然 JWT 可以设置失效时间，但是在有效期内，它是无法作废的。
