token & refresh token 机制总结

token & refresh token 机制总结

废话

我在项目上写了个配置页面，之前很简单直接登录，毕竟配置页面自己人用就没有做token机制，后来公司的安全审核不过，现在要加上token和刷新机制。小结一下。

token和刷新机制

token机制就是在登录成功后返回一个token，并缓存起来，之后每个请求头里带上token，后端验证不通过返回401，前端就直接跳转到登录页。这样就能防止直接访问某个链接就能跳到登录页的尴尬局面。

token刷新机制就是在使用的时候使用某个机制使得这个token不过期，不会跳转到登录页。而没有使用的时候token会过期，他隔得太久了再调接口就是401，就会跳到登录页。

两种token刷新机制

第一种（后端提供刷新接口）

客户端		服务端
---	发送username & password	--->
<---	返回accesstoken & refreshtoken	---
---	访问接口携带accesstoken	--->
<---	返回信息/401	---
---	accesstoken过期访问刷新接口携带refreshtoken	--->
<---	返回新的accesstoken/401	---
---	访问接口携带新的accesstoken	--->
<---	返回信息/401	---

这种情况下 refreshtoken可以设置的时间长一点，而accesstoken设置的时间短一点，我们固定一个用户活跃周期；

活跃周期 = token周期 * 2 ；

eg：活跃周期(at);token周期(et);accesstoken(5 min);refreshtoken(1 day);
用户在15:00登录，返回token生命周期(et)是[15:00-15:05];用户活跃周期为[15:00-15:10];
如果用户在15:06调用接口，携带accesstoken会返回401过期，此时在活跃周期范围内，则调用refreshtoken刷新接口，返回新的accesstoken;
此时：et[15:06-15:11],at[15:06-15:16];
如果用户在15:17分调用接口携带accesstoken会返回401过期，此时不再活跃周期内，则跳转到登录页；

第二种（靠前端cookie实现）

客户端		服务端
---	发送username & password	--->
<---	返回accesstoken	---
cookie存储设置过期时间
---	访问接口携带accesstoken	--->
<---	返回信息/401	--->
调用成功，覆盖延长cookie过期时间		--->

这种情况后端accesstoken可以设置的时间长一点；

前端将token存在cookie中，维护一个过期时间，每次调用接口成功后就覆盖延长这个过期时间，不调用接口的时候自然会超时了；

以上；