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

[MingLovesLife]

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

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

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

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

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

PS：轻喷，心平气和

[qhd1988]

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

[neptuno]

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

[wzj92712]

这一切的前提是 HTTPS.
如果有 HTTPS.可以保证你只会被重放攻击.不会真正泄漏 token 的值.

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

个人的理解.不一定完全正确.

[lidashuang]

refreshToken 不能访问资源啊

[lidashuang]

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

[jifengg]

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

[635925926]

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

[unlimitedsola]

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

[firstmetcs]

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

[ScepterZ]

2 、rt 一般会存数据库，所以有办法踢，at 可以接受不能踢，有效期可以很短

[InkStone]

@wzj92712 https 不能重发的。高版本 tls 如果没对握手信息做记录，会话结束后，你拿着私钥都没法把流量解密。更不要说重放了。
这种我理解更多还是防 XSS 。

[maichael]

1. refreshToken 不应该能访问资源服务器，简单来说 RT 和 AT 访问的“服务器”都是不一样的。
2. 这是防中间人的问题，跟是否使用 RT&AT 方案无关，这是 HTTPS 等方案的事。
3. 不行，跟 1 同理，AT 和 RT 是访问不同服务器的钥匙，你有 AT 不代表你有 RT ；抛开权限不同这点，如果后端实现了自动刷新，那就相当于 AT 和 RT 合一，又回到了单一 token 的方案了。

延伸谈一下，AT&RT 与单 Token 的方案最大的区别是把“获取授权”跟“获取资源”两个行为彻底分离，前者是一个高危害低频率的行为，后者是一个低危害高频率的行为（这里的危害是指 Token 泄漏后带来的影响）；越高频率就意味着越高的暴露风险，所以对于高危害的行为，单独出来放在一个低出现频率的 Token 能提高安全性。

[ttimasdf]

不负责任的盲猜一下，没有开发经验纯盲猜啊

弄个有效期短的临时 ak ，对热缓存和集群部署更友好，token 表直接放内存里面弄个 kv cache 查，肯定比每次请求查用户表去校验 ak ，性能更高一点，只有 refresh token 换 ak 的时候，才需要查一下用户表，验证一下 refresh token 是否有效。

[lambdaq]

放弃 jwt 直接全部服务器存状态吧。

[follower]

这玩意是用来单点登录的
双 token 方案既减轻了服务器压力，又对用户的登录态具有一定的控制，其实是个折中的方案

[cat]

@maichael 换句话说，就是用 RT 代替了账号密码，如果每次请求都携带账号密码，则暴露的风险更高

[johnnyNg]

看看腾讯云，token 过期，直接弹窗登录就好了，不用跳到登录页面

[SilentRhythm]

at：一般是 jwt ，无状态服务颁发后后端无法控制，而且承载实际权限，所以为了安全，设计有效时间一般较短
rt：at 有效期短势必需要刷新了，那么刷新 ak 有哪些方案可选？：
1. at 刷新 at：那我还不如直接长有效时间 at ，安全考虑，不成立；
2. username/password 刷新 at：username/password 手动输入体验就差，存放在 local-stroage 又太危险了；
3. rt：折中方案

[myderr]

这个是一个折中方案，jwt 是无状态的嘛，如果签了一个很长的 at,那么这个用户就无法控制（ ban ）了。但是有个 rt ，那么类似于多久让前端主动请求一下用户状态。

[purringpal]

增加操作空间吧，如果后端什么监控和防护措施都没有，那就是脱裤子放屁，去你所说 rt 被抓包了等于密码泄露。但是如果加了防护措施可以规避异常访问，用的来说就是在用户体验与安全性的折中做法。。