之前有写过一篇文章，不过写的太烂了就被我删了▄█▀█●，怕误人子弟。

token一般用于身份校验，校验http请求者的身份。常使用jwt作为token，但也不一定，只要后台能解析出来令牌内容，能校验用户身份，用什么都行。

令牌的实现就不说了，今天主要说整个身份校验的流程。

访问令牌和刷新令牌

一个令牌通常有到期时间，一个没有到期时间的令牌相当于一个永久的密钥，是绝对不安全的。

当令牌失效过期时，理论上应该重新登陆获取新的令牌。但在某些场合我们希望用户能在不需要额外操作的情况下，自动更新令牌。
之前我的做法是在后端判断过期与否，然后生成新的token放到header中返回给前端。前端判断header中有新的token就更新本地的token。
但这种做法无论对前端还是后端都是比较麻烦的一件事。所以使用了访问令牌+刷新令牌的方案。

Access Token 是访问令牌，用该令牌访问服务器资源。

Refresh Token是刷新令牌，用该令牌换取新的访问令牌。

Access Token的寿命一般很短，Refresh Token的寿命通常会很长。

前后端交互流程

1.生成token

前端调用登录接口获取Access Token和Refresh Token。

2.正常请求

前端拿到Access Token和Refresh Token后将其存在缓存中，每次请求需要校验身份的接口时，将其加在header中的Authorzation中(当然也可以是别的字段)。

3.更新令牌

后端返回令牌过期的消息后，用Refresh Token再去请求更新令牌的接口，获取新的Access Token和Refresh Token。如果Refresh Token过期或失效，那么只能重新登录。

令牌的存储与失效

令牌如何合理的保存，要视具体的业务逻辑而定。比如有的应用只允许用户同一时刻在同一台设备上使用，而有的应用则允许同时在多个设备上使用。

这里分享一下我常用的方案。

我会在用户表里添加一个int型字段tid(token_id)。每当生成令牌时该字段都会自增1，访问令牌和刷新令牌都存有该字段。
当访问资源或更新令牌时，我会校验tid，如果tid对不上则令牌失效。