JWT刷新令牌存储于Cookie易被盗用，求可行的安全解决方案

• 你当前考虑的服务端持久化refresh token白名单是非常有效的基础方案，可进一步优化细节：
  为每个refresh token生成独立的唯一标识jti存储在数据库中，用户每次调用刷新接口获取新access token时，直接作废当前使用的旧refresh token，同时签发新的refresh token返回前端、更新白名单。即使旧refresh token被盗，攻击者也无法用失效的凭证完成刷新。
• 从传输存储层面降低refresh token被盗风险：
  给存储refresh token的Cookie配置全套安全属性：
  • 开启HttpOnly：禁止前端JS读取Cookie，从根源避免XSS攻击窃取token
  • 开启Secure：仅允许HTTPS协议传输Cookie，避免明文传输泄露
  • 设置SameSite=Strict/Lax：防止CSRF攻击挟持用户Cookie发起恶意请求
  • 收缩Domain和Path配置：缩小Cookie的生效范围，避免不必要的场景携带token
• 增加身份特征绑定校验：
  签发refresh token时，绑定客户端的UA信息、IP段（不要绑定完整IP避免移动网络波动导致的误拦截），用户刷新凭证时校验特征是否匹配，不匹配直接作废当前token、要求用户重新登录，即使token被盗也无法跨设备/跨网络使用。
• 补充异常监控与主动失效机制：
  • 给用户提供「退出所有登录设备」功能，调用时直接清空该用户在数据库中的所有refresh token白名单，支持用户主动下线所有登录态
  • 后台配置异常规则检测：例如同一个refresh token被多次调用、短时间内多个不同IP/UA使用同一用户的refresh token发起刷新请求，直接作废该用户所有refresh token，触发二次身份校验
• 高安全场景可采用短有效期+滑动刷新策略：
  将refresh token的固定有效期从7天缩短为2-3天，每次刷新时如果当前refresh token剩余有效期不足1天，自动签发新的7天有效期refresh token返回给前端。正常活跃的用户无感知，长期不活跃的用户token会自动过期，大幅降低token被盗后的可用窗口。

另外你当前不将access token存入Cookie的做法是合理的，access token可以存放在前端内存（如框架的全局状态中，页面刷新自动失效），本身15分钟的短有效期就算泄露风险也极低。

内容的提问来源于stack exchange，提问作者Ritik