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