前言：
截取于原文地址：https://www.jianshu.com/p/a32634a5170c
基于Token的验证原理：
基于token的身份验证是无状态的，我们不再将用户的信息存储于服务器中。这种概念解决了在服务器存储信息时的许多问题。NOSESSION意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
基于Token的身份验证的过程如下：
- 用户通过用户名和密码发送登录请求。
- 服务器端验证用户名和密码。
- 服务器端返回一个带签名的token给客户端并存储该token在服务端（redis）。
- 客户端存储token，并且每次请求api时都要携带token。
- 服务器验证token。
Token的优势：
- 无状态，可扩展
在客户端存储的token是无状态的，并且能够被扩展。基于这种无状态和不存储session信息，负载均衡的服务器就能够将用户的信息从一个服务器上传到其他服务器上。
- 安全性
请求中发送token而不是发送cookie能够防止csrf（跨站请求伪造）。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。补将信息存储在session中，让我们少了对session的操作。
- 可扩展性
token能够创建与其他程序共享权限的程序，也就是说多个站可以共用一个token。
多平台跨域
Cookie是不允许垮域访问的，token支持。
Token的缺陷：
- 占用带宽
正常情况下要比 session_id 更大，需要消耗更多流量，挤占更多带宽，假如你的网站每月有 10 万次的浏览器，就意味着要多开销几十兆的流量。听起来并不多，但日积月累也是不小一笔开销。实际上，许多人会在 JWT 中存储的信息会更多。
- 无法在服务端注销，那么就很难解决劫持问题。
- 性能问题
JWT 的卖点之一就是加密签名，由于这个特性，接收方得以验证 JWT 是否有效且被信任。但是大多数 Web 身份认证应用中，JWT 都会被存储到 Cookie 中，这就是说你有了两个层面的签名。听着似乎很牛逼，但是没有任何优势，为此，你需要花费两倍的 CPU 开销来验证签名。对于有着严格性能要求的 Web 应用，这并不理想，尤其对于单线程环境。
Refresh Token：
Refresh Token它可以避免频繁的读写操作。这种方案中，服务端不需要刷新 Token的过期时间，一旦 Token过期，就反馈给前端，前端使用 Refresh Token 申请一个全新Token继续使用。这种方案中，服务端只需要在客户端请求更新 Token的时候对 Refresh Token 的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。当然 Refresh Token 也是有有效期的，但是这个有效期就可以长一点了，比如，以天为单位的时间。
使用 Token和 Refresh Token 的时序图如下：
登录
业务请求
Token过期
