前言
我在项目上写了个配置页面,之前很简单直接登录,毕竟配置页面自己人用就没有做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];at[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中,维护一个过期时间,每次调用接口成功后就覆盖延长这个过期时间,不调用接口的时候自然会超时了;
以上;