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

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

1. refreshToken 不应该能访问资源服务器，简单来说 RT 和 AT 访问的“服务器”都是不一样的。 2. 这是防中间人的问题，跟是否使用 RT&AT 方案无关，这是 HTTPS 等方案的事。 3. 不行，跟 1 同理，AT 和 RT 是访问不同服务器的钥匙，你有 AT 不代表你有 RT ；抛开权限不同这点，如果后端实现了自动刷新，那就相当于 AT 和 RT 合一，又回到了单一 token 的方案了。 延伸谈一下，AT&RT 与单 Token 的方案最大的区别是把“获取授权”跟“获取资源”两个行为彻底分离，前者是一个高危害低频率的行为，后者是一个低危害高频率的行为（这里的危害是指 Token 泄漏后带来的影响）；越高频率就意味着越高的暴露风险，所以对于高危害的行为，单独出来放在一个低出现频率的 Token 能提高安全性。

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

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

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

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

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

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

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