不懂就问，请教一下前端无感刷新 token 到底有没有意义？

在技术网站看到过无数次前端无感刷新 token 的文章，一直很费解，为啥要刷新 token 呢？那前端给 token 刷新了，token 还有啥意义呢？

文章给出的原因是，用户正操作着呢，token 突然过期，跳登录页用户体验不好。

实现步骤：
accessToken 简称 at ，refreshToken 简称 rt
1. rt 有效期长，at 有效期短
2. at 过期了拿 rt 换 at ，重新请求

疑问：
1. 既然 rt 长期有效，直接用 rt 有啥问题
2. 如果从安全考虑，rt 被抓包拿了，也没辙呀
3. 既然后端知道用户操作了，如果是非异常操作，就自动给 token 延时行不？

不知道该方案具体是为了什么，还请大神们赐教。希望接到类似需求老哥们聊聊

PS：轻喷，心平气和

我觉得只是增加抓包难度罢了,提升用户体验只是带来的"副作用", 安全不安全,主要看你项目有没有真金白银的价值,有的话,管你啥 refresh_token 还是啥,分分钟给你抓出来

这么一说确实有道理的，小厂反正无所谓怎么搞都行。大厂的话我的理解就是 refreshToken 可以多一道控制，accessToken 签出之后无法控制失效（除非加黑名单），但 refreshToken 可以控制下一次 accessToken

这一切的前提是 HTTPS. 如果有 HTTPS.可以保证你只会被重放攻击.不会真正泄漏 token 的值. 1.小项目这样做没问题. 只不过如果 rt 可以请求资源. 那就是说可能会被一直重放攻击. 如果 rt 只能换 at.at 过期了.他就不能重放了(他得再次抓包). 安全一丢丢. 2.基于前提.rt 不会被获取值的. 3.可行但怪麻烦的,不如直接用长期 token 个人的理解.不一定完全正确.

refreshToken 不能访问资源啊

accessToken 有效期短一点，相对安全一点

我以前碰到的时候思考的，不一定对：“服务器端校验 refreshtoken 消耗的资源比 accesstoken 大。” 更深的原因就没有细究了。

我也无法理解为啥要 jwt ，短短的 token 不香吗

Access Token 可能是 JWT, 服务端收到时可以通过校验签名来确认是否有效, 不一定需要查询数据库或做完整的校验. JWT 弊端是签出后无法轻松控制失效, 所以需要 Refresh Token 来弥补.

我理解的每个请求都有 access_token 的传递，但是只有登录、刷新 token 等操作才会传递 refresh_token ，这样的话 refresh_token 被抓包的几率小多了，然后 access_token 泄露的话那么下次过期自然被抓包的那次就不能再使用了