Token Intro
Token 概述
Token 的作用/目的
背景（引言）
我们都知道一般接口但是通过 HTTP 协议来进行数据交换的，而 HTTP 协议的特点是，无状态，工作前通过三次握手建立连接，工作完成后立刻通过四次挥手断开连接，每次连接都是独立存在的（这里不谈keep-alive的http），没有任何状态将请求串联成一个整体，因此每次都需要重新验证是身份，即耗费了性能，也给黑客的攻击留下隐患。
继而由此，我们需要一种能够存储当前状态的技术，此时
cookies粉墨登场。
Cookies 存储 Token
Cookie 就是来弥补 HTTP 无状态的问题的，Cookie可以作为一个状态保存的状态机，用来保存用户的相关登录状态，当第一次验证通过后，服务器可以通过set-cookie令客户端将自己的token保存起来，当下一次再发送请求的时候，直接带上token即可，而服务器收到到客户端发送的token`后，进行验证（比如解密出用户信息，或者将其当作一个钥匙，去服务端数据库中拿数据来校验），则直接信任该连接，不再需要进行额外验证操作。
LocalStorage 存储 Token
从目的出发本质上与cookie存储没有区别，都是存储身份认证信息
简单来说，就是一种验证信息，客户端通过登录验证后，服务器会返回给客户端一个加密的 token，然后当客户端再次向服务器发起连接时，带上token，服务器直接对token进行校验即可完成权限校验。
而将 token 存储在 localStorage 内，有以下区别：
- Cookie 作为 HTTP 规范，其出现历史久远，因此存在一些历史遗留问题，比如跨域限制等，并且 Cookie 作为 HTTP 规范中的内容，其存在默认存储以及默认发送的行为，存在一定的安全性问题（CSRF攻击）
CSRF攻击：由于用户登录校验信息在cookie中，则如果当前浏览器登陆了A网站后，在B网站（攻击网站）中存在一个请求指向了A，此时由于 cookie 是基于 【客户端 - 服务器】，所以此时二者都没变的情况下，cookie 将会被携带进去作为一次合法请求，如此实现了攻击。
A: 已登录，将认证令牌放在cookie: { session: xxx }
用户进入B网站:
进入后B网站立即执行一条请求 https://A.com/post/deleteAll 删除全部文章
此时，由于A网站已登录，该请求会携带上上次登录设置的cookie，从而认为是一次合法请求。
--> 结果：当前用户在A网站的所有文章都被删除了。
localStorage 是浏览器提供的存储功能，能够以键值对的方式进行数据存储，且数据能持久化被存储，即使浏览器关闭后也不会清除。而 localStorage 不会像 cookie 一样自动被带到请求中，故此可以避免CSRF攻击的发生。
从上面对于 localStorage Token 和 Cookie token 的分析，我们知道了 Cookie 由于存储的内存空间只有 4kb，因此存储的主要是一个用户 id，其他的用户信息都存储在服务器的 Session 中，而 localStorage 的内存空间更大（5MB左右），用户信息可以存储到 Token 中，返回给用户自行存储，因此可以看出，采用 Cookie 的话，由于所有用户都需要在服务器的 Session 中存储相对应的用户信息，所以如果用户量非常大，这对于服务器来说，将是非常大的性能压力，而Token 将用户信息返回给客户端各自存储，也就完全避开这个问题了。
Token 与 refresh Token
原始的认证 Token
最原始的认证 Token，即当认证完毕后，服务端给该token设置有效期，在有效期内接口携带该token（不管是cookie/其他地方的参数），服务端都认为是合法有效的。
优点：
简单有效，无需太多复杂的token管理逻辑，对于快速开发，安全性要求不太高的项目来说很方便。
弊端：
设置一个固定的过期时间，如果时间过短，则会导致用户体验不好，可能用户登录后，正在填写表单时突然就过期退出了；如果时间过长，则会将安全性问题放大，一旦被非法获取后长时间未过期，在这段时间攻击者则可以利用该token持续进行攻击了。
refresh token
为了解决单纯 token 过期时长问题而解决
从上面我们能知道，token 过期时间设置的过长/过短都有各自的缺陷，过长时安全有问题，而过短时则用户体验不好。
从这点出发，提出了 refresh token 的方案。
服务端在下发 token 的同时，下发一个 refreshToken 该 refreshToken 可用于请求一个新的有效 token。
为 token 设置一个很短的有效期，并设置一套保活逻辑，如有效期为24h（包括refreshToken），保活时间为 1h，则当用户在 1h 内没有进行请求时（或部分请求，有些接口服务端可设置黑白名单），会将该 token 过期。
此时前端使用过期 token 发出请求，服务端返回特定错误后，前端向服务端发出 api/refreshToken 请求，将 refreshToken 传入，获取一组新的 token / refreshToken。
该 refreshToken 过程应该是用户无感知的，如此能够做到用户体验的提升，同时满足了系统安全性要求。
