共计 1159 个字符，预计需要花费 3 分钟才能阅读完成。
前言
记录一下前后端分离下————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 过期时间到了，依然没有使用系统，那么将判定为不活跃用户，此时应当重定向到登录页了
最后
篇幅较短，主要是延续上一篇 前后端分离应用——用户信息传递 遗留问题做一下总结。如果你有更好的做法，欢迎留言告知我，谢谢啦。后续会不定期更新原创文章，欢迎关注公众号「张少林同学」！
