在之前的工作经历中，遇到与用户资金相关的业务 为了保障用户的权益，我提出需要保证token安全，于是重构登录服务。
使用的便是 refresh token。
token，作为权限守护者，最重要的就是「安全」。
业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但过短的有效期会造成 access token 经常过期，过期后怎么办呢？
一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。
另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。
• access token 用来访问业务接口，由于有效期足够短，盗用风险小，也可以使请求方式更宽松灵活
• refresh token 用来获取 access token，有效期可以长一些，通过独立服务和严格的请求方式增加安全性；由于不常验证，也可以如前面的 session 一样处理
有了 refresh token 后，几种情况的请求流程变成这样：
怕access token泄露 那就不怕 refresh token泄露吗？
怕，非常怕。
Refresh Token 一旦泄露，后果其实比 Access Token 泄露更严重，因为它是获取 Access Token 的"长期通行证"。
但是，之所以愿意承担这个风险，是因为 Refresh Token 的泄露风险在实际操作中是更可控的。
1. 存储位置不同（最核心的防御）
这是两者最大的区别，也是安全性的关键所在。
Access Token：通常存储在浏览器的 内存 或 LocalStorage 中。
风险：容易受到 XSS（跨站脚本攻击） 的窃取。因为前端 JavaScript 代码需要读取它来放在 HTTP Header 里发送给后端。
Refresh Token：通常存储在 HttpOnly Cookie 中。
防御：HttpOnly 属性意味着 JavaScript 无法读取 这个 Cookie。即使黑客注入了恶意脚本（XSS 攻击），脚本也无法偷走 Refresh Token。
传输：浏览器会在后台自动带上这个 Cookie 发送给认证服务器，不需要前端代码干预。
2. 使用频率与暴露面
Access Token：每次请求业务接口（如获取用户信息、下单）都要用到。
暴露面：在网络中传输次数极多，被中间人劫持或在日志中泄露的概率相对较高。
Refresh Token：只有在 Access Token 过期（比如 2 小时后）才使用一次。
暴露面：传输频率极低，被截获的概率大大降低。
3. 严格的验证环境（"严查"）
因为 Refresh Token 权限太大，认证服务器在验证它时会非常严格，通常会绑定以下信息：
IP 地址绑定：如果申请 Refresh Token 时是北京的 IP，那么使用它换新 Token 时也必须是北京的 IP。
User-Agent 绑定：必须是同一台设备、同一个浏览器。
客户端 ID 绑定：防止 Token 被拿去别的客户端使用。
如果验证不匹配，服务器会直接拒绝，并可能拉黑该用户强制重新登录。
4. 撤销机制与"一次一密"
黑名单/撤销列表：Access Token 因为是无状态的（JWT），通常很难在过期前撤销。但 Refresh Token 通常是有状态的（存储在 Redis 或数据库中）。
一旦发现异常（比如用户点击了"退出登录"，或者系统检测到异地登录），服务器可以直接在数据库里把 Refresh Token 删掉。一旦删掉，黑客手里的 Refresh Token 就失效了。
滚动刷新：有些高安全级别的系统，每次使用 Refresh Token 换取新 Access Token 时，会同时颁发一个新的 Refresh Token，并作废旧的。
这意味着黑客如果偷了一个旧的 Refresh Token，一旦用户正常使用了一次，黑客手里的 Token 就立刻作废了。