@billbur 确实粗浅😂

@lusxh #40 对的，因为我觉得根本不需要把问题复杂化，把问题简单化才能更好的避免引发各种问题，当然这是我个人的经验之谈，不是什么正解

我给你举个不恰当的方便理解的例子. 有一个系统, 他的安全等级较高, 采用了天顶星科技都无法破解的加解密系统存储用户名, 采用了天顶星科技的都无法创建碰撞的 hash 算法存储密码 一次加解密用户名开销要 30 秒, 一次 hash 开销要 5 秒 这时候,不用 refresh token 和用 refresh token 的性能差异就非常明显了... 然后这只是极端情况, 但是所需计算性能的维度因素是可以转换的 现实中你可能并没有这种加密要 30 秒的算法, 但是你可能有 10 亿活跃并发请求, 照样压死算法执行器

如果不用双 token,你准备让你的单 token 多久失效，如果你有多个系统需要鉴权，如果这时候要控制用户访问，这时候单 token 应该怎么做？

@realpg 对的, 相同的问题可以问一下 ssl 为什么要用同步密钥加密

像对接微信接口的时候，比较适合这种场景，服务器和服务器的交换 我也总觉得用户端不适用这种场景

主要就是降低了服务器查 token 的开销，还有就是能存点公开信息放里面，后面也不用再查。 Access Token 里面存了用户信息，如果 Access Token 没过期就可以直接用里面的数据，Access Token 有过期时间，前端一般会在过期前几分钟的调用续签接口（通过 Refresh Token ），让后端签发 Access Token ，Refresh Token 是做了存储的，所以可以控制用户是否还能续签，从以前的每次调用都要查 Token 到现在一段时间后才查 Refresh Token ，降低了开销（一般续签接口还会做限制，防止频繁续签）。 问题就是 Access Token 有时效，不能马上过期，这是一个毛病

正在学习这个功能，基于现有了解，Access Token 放 storage ，允许 js 读写，Refresh Token 要放 cookie ，http only 不能 js 读取。