前言
记录一下前后端分离下————token超时刷新策略!
需求场景
昨天发了一篇记录 前后端分离应用——用户信息传递 中介绍了token
认证机制,跟几位群友讨论了下,有些同学有这么一个疑惑:token
失效了,应该怎么做?强制定向到登录页?
其实理论上如果是活跃用户,token
失效后,假如用户正在操作表单,此时突然定向到登录页面,那用户体验太差了。
实现目标
- 延长
token
过期时间 - 活跃用户在
token
过期时,在用户无感知的情况下动态刷新token
,做到一直在线状态 - 不活跃用户在
token
过期时,直接定向到登录页
登录返回字段
如何签发token
,请看上一篇推文,这里不做过多介绍。先看看登录接口返回的数据如下:
@Data
public class LoginVo implements Serializable {
private static final long serialVersionUID = 6711396581310450023L;
//...省略部分业务字段
/**
* token令牌 过期时间默认15day
*/
private String jwt;
/**
* 刷新token 过期时间可以设置为jwt的两倍,甚至更长,用于动态刷新token
*/
private String refreshJwt;
/**
* token过期时间戳
*/
private Long tokenPeriodTime;
}
具体返回字段的意义请看注释,这里再简要说明:
- jwt:用户正常访问接口时提交的
token
,过期时间设置长一些,15day吧 - refreshJwt:刷新
token
过期时间可以设置为jwt
的两倍,甚至更长,用于动态刷新token
时候提交后台验证 - tokenPeriodTime:
token
过期时间戳,前端每次调用接口前需要主动判断是否已经过期,如果过期则提交refreshJwt
访问token
刷新的接口进行刷新
动态刷新token
前端检测到token
过期后,携带refreshJwt
访问后台刷新token
的接口,服务端在拦截器中依然对refreshJwt
进行解析鉴权
- 假如
refreshJwt
也过期了,提示登录过期,强制跳转登录页 - 假如
refreshJwt
还在有效期,则签发新的token
返回,前端使用最新的token
进行接口请求
总结
- 如果是活跃用户,那么允许他在
refreshJwt
过期时间与token
过期时间的差值这段时间内,不停的动态刷新token
,使其做到无感知的状态下一直保持登录状态 - 如果用户不活跃,在
refreshJwt
过期时间到了,依然没有使用系统,那么将判定为不活跃用户,此时应当重定向到登录页了
最后
篇幅较短,主要是延续上一篇 前后端分离应用——用户信息传递 遗留问题做一下总结。如果你有更好的做法,欢迎留言告知我,谢谢啦。后续会不定期更新原创文章,欢迎关注公众号 「张少林同学」!