3. Token 鉴权

现在已经得知，Session-Cookie 的一些缺点，以及 Session 的维护给服务端造成很大困扰，必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。那有没有更好的办法？
那 Token 就应运而生了

3.1 什么是 Token（令牌）

Token 是一个令牌，客户端访问服务器时，验证通过后服务端会为其签发一张令牌，之后，客户端就可以携带令牌访问服务器，服务端只需要验证令牌的有效性即可。
一句话概括；访问资源接口（API）时所需要的资源凭证

一般 Token 的组成：
uid (用户唯一的身份标识) + time (当前时间的时间戳) + sign (签名，Token 的前几位以哈希算法压缩成的一定长度的十六进制字符串)

Token 的认证流程图：

Token 认证步骤解析：
客户端： 输入用户名和密码请求登录校验；
服务器： 收到请求，去验证用户名与密码；验证成功后，服务端会签发一个 Token 并把这个 Token 发送给客户端；
客户端： 收到 Token 以后需要把它存储起来，web 端一般会放在 localStorage 或 Cookie 中，移动端原生 APP 一般存储在本地缓存中；
客户端发送请求： 向服务端请求 API 资源的时候，将 Token 通过 HTTP 请求头 Authorization 字段或者其它方式发送给服务端；
服务器： 收到请求，然后去验证客户端请求里面带着的 Token ，如果验证成功，就向客户端返回请求的数据，否则拒绝返还（401）；

Token 的优点：
服务端无状态化、可扩展性好： Token 机制在服务端不需要存储会话（Session）信息，因为 Token 自身包含了其所标识用户的相关信息，这有利于在多个服务间共享用户状态
支持 APP 移动端设备；
安全性好： 有效避免 CSRF 攻击（因为不需要 Cookie）
支持跨程序调用： 因为 Cookie 是不允许跨域访问的，而 Token 则不存在这个问题

Token 的缺点：
配合： 需要前后端配合处理；
占带宽： 正常情况下比  sid  更大，消耗更多流量，挤占更多宽带
性能问题： 虽说验证 Token 时不用再去访问数据库或远程服务进行权限校验，但是需要对 Token 加解密等操作，所以会更耗性能；
有效期短： 为了避免 Token 被盗用，一般 Token 的有效期会设置的较短，所以就有了 Refresh Token；

3.2 什么是 Refresh Token（刷新 Token）

业务接口用来鉴权的 Token，称之为 Access Token。

为了安全，Access Token 有效期一般设置较短，以避免被盗用。但过短的有效期会造成 Access Token 经常过期，过期后怎么办呢？
一种办法是：刷新 Access Token，让用户重新登录获取新 Token，会很麻烦；
另外一种办法是：再来一个 Token，一个专门生成 Access Token 的 Token，称为 Refresh Token；

Access Token： 用来访问业务接口，由于有效期足够短，盗用风险小，也可以使请求方式更宽松灵活；
Refresh Token： 用来获取 Access Token，有效期可以长一些，通过独立服务和严格的请求方式增加安全性；由于不常验证，也可以如前面的 Session 一样处理；

Refresh Token 的认证流程图：

Refresh Token 认证步骤解析：

客户端： 输入用户名和密码请求登录校验；
服务端： 收到请求，验证用户名与密码；验证成功后，服务端会签发一个 Access Token 和 Refresh Token 并返回给客户端；
客户端： 把 Access Token 和 Refresh Token 存储在本地；
客户端发送请求： 请求数据时，携带 Access Token 传输给服务端；

服务端：
验证 Access Token 有效：正常返回数据
验证 Access Token 过期：拒绝请求

客户端 ( Access Token 已过期) ： 则重新传输 Refresh Token 给服务端；
服务端 ( Access Token 已过期) ： 验证 Refresh Token ，验证成功后返回新的 Access Token 给客户端；
客户端： 重新携带新的 Access Token 请求接口；

3.3 Token 和 Session-Cookie 的区别

Session-Cookie 和 Token 有很多类似的地方，但是 Token 更像是 Session-Cookie 的升级改良版。

存储地不同： Session 一般是存储在服务端；Token 是无状态的，一般由前端存储；
安全性不同： Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击；
支持性不同： Session-Cookie 认证需要靠浏览器的 Cookie 机制实现，如果遇到原生 NativeAPP 时这种机制就不起作用了，或是浏览器的 Cookie 存储功能被禁用，也是无法使用该认证机制实现鉴权的；而 Token 验证机制丰富了客户端类型。

如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。