在讨论安全之前，要先定义什么是安全，或者说要应对的威胁模型是什么。

- 如果是 token 伪造，那 session （也就是你说的 token+redis ）和 JWT （双 token ）没区别，都是后端签发的。

- 如果说是身份冒用，两者也没区别，只要持有合法 token 就视作有效。

- 如果指的是 token 撤销，那么 session 比 jwt 好一点，因为它可以实时撤销，而 jwt 只能等它过期。



“性能也不见得差”这句话有毛病。session 方案的逻辑是有个中心化的实时鉴权后端，要负责对所有业务请求进行身份认证。现实里这个单点是极其脆弱的，水平扩展能力也非常有限。

由此诞生的 JWT 之类的方案，并不是要做得比 session 更安全，而是要解决 session 方案的性能瓶颈。

准确来说，解决性能瓶颈靠的是通过无状态 AccessToken ，将鉴权转移到每个业务单元，业务单元只需要解码而不需要实时后端查询。

为了让 JWT 方案也能达到和 session 方案一样的安全水平，那就要将 AccessToken 的有效期设定得越短越好。

但是 JWT 方案是无状态的，如果要获得新的 AccessToken 是无法像 session 一样自动更新的，必须要走一遍完整的登录验证过程。


所以就有了 RefreshToken ，它解决的是方便获得短时效 AccessToken 的问题。这个“双”token 的重点是方便。

PS 稍微补充一点：如果是 web 应用场景，RefreshToken 多数存储于 HttpOnly/Secure/SameSite=Strict cookies 中，防止 js 读取，也避免 XSS 攻击（因为即便后端被注入恶意代码，这个代码被当前用户执行后也无法获得 cookie 内容）。AccessToken 存储于内存变量中，通过 js 代码以 header 的形式传递，这样可以防止 csrf 攻击（因为跨域的时候不可能带上这个 header ）。