refresh token的作用是什么？其安全存储方式及后端安全措施有哪些？

从refresh token的设计本质出发，它作为高敏感的长时效凭证，防护逻辑不能和短时效的access token混为一谈——你提到的“短时效access token缩小劫持影响、长时效refresh token换发新凭证”的核心设计是行业通用的安全范式，对应的存储和后端防护逻辑完全是围绕“降低refresh token被劫持后的损失”展开的。

客户端侧的安全存储位置选型 #

判断存储位置是否安全的核心标准只有一个：攻击者能否通过XSS、流量窃听、跨站请求等常见前端攻击轻易读取到这个token。

• Web端场景的最优选择：配置了HttpOnly + Secure + SameSite=Strict属性的专属Cookie
  三个属性全部生效后，页面上运行的任何JS代码都无法读取到Cookie中存储的refresh token，从根上挡住绝大多数XSS脚本偷token的路径；Secure属性强制要求只有HTTPS加密传输才能携带该Cookie，避免明文网络环境下的流量窃听；SameSite属性拉满后，跨站请求不会自动携带该Cookie，直接抵消CSRF攻击窃取的可能。
  这里必须明确避坑：绝对不要把refresh token存在localStorage、sessionStorage、无HttpOnly属性的普通Cookie里——只要JS有读取权限，哪怕是嵌入页面的第三方广告、统计脚本出了XSS漏洞，都能顺走这个高敏感凭证。也不要把refresh token拼在URL参数里传递，这类参数会被留存到访问日志、浏览器历史记录中，泄露风险极高。
• 原生移动端/App场景的存储选择
  直接使用系统提供的硬件级加密存储区：iOS优先用Keychain存储关联用户账号的refresh token，Android优先用Keystore加密存储，不要自己写本地明文文件存token，更不要存在App内可被其他应用读取的公共存储目录下。

后端必须落地的配套安全机制 #

没有任何一种存储方式能做到绝对安全，后端的防护才是兜底的核心：

• 签发时绑定强身份校验维度
  每个refresh token签发时，就和对应的用户ID、初始签发时的IP段、设备指纹、客户端类型做硬绑定。后续用户拿着这个refresh token来换取新的access token时，必须逐项校验这些匹配维度：如果出现IP归属地突变、设备指纹完全不匹配、客户端类型跨类型切换的情况，直接拒绝换token请求，将该关联的refresh token立即作废，同时触发用户的异常登录通知。
• 严格执行refresh token一次性轮转逻辑
  “用refresh token换新时同时签发全新refresh token”的机制必须严格落地：旧的refresh token只要被使用一次，立刻进入永久失效名单。一旦检测到同一个旧的refresh token被重复提交请求（大概率是token被劫持后攻击者的使用痕迹），不要只拒绝单次请求，要直接作废对应用户名下所有关联的有效refresh token，强制用户重新通过账号密码/二次验证登录，从根源上切断token链被劫持后的持续攻击路径。
• 做差异化的refresh token有效期控制
  不要对所有场景一刀切设置超长有效期：用户在标记为“常用设备”的终端登录时，可以给7-14天的长时效refresh token；如果是未标记的陌生设备、刚完成敏感操作（比如改密码、换绑手机号）的场景，就只给1-2小时的短时效refresh token；用户主动触发退出登录时，必须立即作废该用户账号下所有未过期的refresh token，不要等token自然到期。
• 全链路的异常操作审计
  所有使用refresh token换发新token的请求做全量日志留存，重点监控短时间内跨地域、跨设备的异常token使用行为，碰到可疑请求时直接触发二次身份校验流程，确认是本人操作后再放行。

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