Token 鉴权

Token 鉴权 §

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

于是 Token 就应运而生了

Token（令牌） §

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

Token 的组成 §

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

Token 的认证流程图 §

Token 认证步骤解析 §

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

Token 的优点 §

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

Token 的缺点 §

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

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 认证步骤解析 §

1. 客户端： 输入用户名和密码请求登录校验。
2. 服务端： 收到请求，验证用户名与密码；验证成功后，服务端会签发一个 Access Token 和 Refresh Token 并返回给客户端；
3. 客户端： 把 Access Token 和 Refresh Token 存储在本地；
4. 客户端： 请求数据时，携带 Access Token 传输给服务端；
5. 服务端：
   • 验证 Access Token 有效：正常返回数据
   • 验证 Access Token 过期：拒绝请求
6. 客户端 ( Access Token 已过期) ： 则重新传输 Refresh Token 给服务端；
7. 服务端 ( Access Token 已过期) ： 验证 Refresh Token ，验证成功后返回新的 Access Token 给客户端；
8. 客户端： 重新携带新的 Access Token 请求接口；

Token 和 Session-Cookie 的区别 §

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

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