JWT访问与刷新令牌存储咨询：Cookie存贮方案是否合理？

当前实现的问题 #

你把access token和refresh token都存入HTTP-only Cookie的做法，确实存在不必要的安全风险：refresh token的有效期通常远长于access token，每次请求都携带它会大幅增加其被拦截、泄露的概率——毕竟refresh token一旦泄露，攻击者可以长期获取新的access token，危害远大于单次的access token泄露。

纠正你的理解误区：不必用localStorage存access token #

你想到的"access token存localStorage、refresh token存Cookie"方案其实并非最优解，因为localStorage存在XSS窃取风险（恶意脚本可直接读取localStorage内容）。更安全的做法是：

• refresh token: 继续存在HTTP-only、Secure、SameSite=Strict的Cookie中（这部分你的思路是对的，完全隔绝XSS窃取）
• access token: 存在前端内存中（比如React的Context、Redux Store或者组件state里）

具体流程实现 #

1. 登录成功后，后端：
   • 设置refresh token的HTTP-only Cookie（配置Secure确保仅HTTPS传输，SameSite=Strict防止CSRF）
   • 将access token作为响应体返回给前端
2. 前端接收access token后，存入内存状态，后续所有API请求都在请求头中携带：Authorization: Bearer ${accessToken}
3. 当API请求返回401（access token过期）：
   • 调用后端的刷新token接口（此时浏览器会自动携带Cookie中的refresh token）
   • 后端验证refresh token有效后，返回新的access token
   • 前端更新内存中的access token，并重发之前失败的请求
4. 页面刷新时：
   • 内存中的access token丢失，前端立即调用刷新token接口，用Cookie里的refresh token获取新的access token
   • 获取成功后再初始化应用状态，正常使用

为什么内存存储更安全？ #

• 内存中的数据不会持久化，页面关闭或刷新后就会消失，即使出现XSS攻击，恶意脚本只能在当前会话中窃取token，无法长期留存
• 避免了localStorage被XSS脚本直接读取的风险，同时也不会像Cookie那样每次请求都携带token（减少access token的暴露次数）

内容的提问来源于stack exchange，提问作者adri.lh