https://segmentfault.com/a/1190000013010835#comment-area
https://segmentfault.com/a/1190000020143933?utm_source=sf-related
https://blog.csdn.net/wang839305939/article/details/78713124
Token认证流程
- 客户端使用用户名跟密码请求登录
- 服务端收到请求，去验证用户名与密码
- 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
- 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者Local Storage 里
- 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
- 服务端收到请求，然后去验证客户端请求里面带着的 Token（request头部添加Authorization），如果验证成功，就向客户端返回请求的数据 ，如果不成功返回401错误码，鉴权失败。
https://www.lishuaishuai.com/nodejs/1167.html?soure=jj
Token和session的区别
session-cookie的缺点：
（1）认证方式局限于在浏览器中使用，cookie 是浏览器端的机制，如果在app端就无法使用 cookie。
（2）为了满足全局一致性，我们最好把 session 存储在 redis 中做持久化，而在分布式环境下，我们可能需要在每个服务器上都备份，占用了大量的存储空间。
（3）在不是 Https 协议下使用 cookie ，容易受到 CSRF 跨站点请求伪造攻击。
token的缺点：
（1）加密解密消耗使得 token 认证比 session-cookie 更消耗性能。
（2）token 比 sessionId 大，更占带宽。
两者对比，它们的区别显而易见：
（1）token 认证不局限于 cookie ，这样就使得这种认证方式可以支持多种客户端，而不仅是浏览器。且不受同源策略的影响。
（2）不使用 cookie 就可以规避CSRF攻击。
（3）token 不需要存储，token 中已包含了用户信息，服务器端变成无状态，服务器端只需要根据定义的规则校验这个 token 是否合法就行。这也使得 token 的可扩展性更强。
token是一种用户标识，表示用户身份，类似身份证件。
Token是在服务端产生的。如果前端使用用户名和密码向服务端请求认证，服务端认证成功，服务端会返回Token 给前端。前端可以在每次请求的时候带上Token 证明自己的合法性地位。如果这个Token在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。
使用Token 和 Refresh Token的时序图：
1.登录：
2. 业务请求：
3.Token过期，刷新Token
分离认证服务：
当Token 无状态之后，单点登陆就变得容易了。前端拿到一个有效的Token，它就可以在任何同一体系的服务上认证通过，只要它们使用同样的**和算法来认证Token的有效性。
如果Token 过期了，前端仍然需要去认证服务更新 Token：