基于Cookie存储JWT的React SPA架构：是否需要刷新令牌？

我正在使用后端Spring Security为React单页应用（SPA）实现安全防护。经过大量调研后，我采用了以下方案：

• 全程使用HTTPS
• POST /login接口接收凭证后，以Cookie形式返回JWT_TOKEN和XSRF_TOKEN。其中JWT_TOKEN由我自行构建，XSRF_TOKEN由Spring Security处理。两个Cookie均设置为Secured和SameSite=Strict，且JWT_TOKEN为HttpOnly。
• 后续API请求需携带X-XSRF-TOKEN请求头，该值读取自上述Cookie，Spring Security会对二者进行校验；JWT则自动携带并由过滤器校验。
• 每次使用XSRF令牌时，Spring Security会生成新令牌以防止会话固定攻击
• Spring Security已开启XSS防护

现在我对刷新令牌存在疑问，查阅到的信息众说纷纭。请问在该架构下是否需要刷新令牌？如果需要，该如何妥善处理？

回答 #

是否需要刷新令牌？ #

需要，核心原因有两点：

1. 降低JWT泄露风险：如果JWT设置较长有效期，一旦因极端情况（如用户设备被盗、中间人攻击）泄露，攻击者可长期冒用用户身份。缩短JWT有效期后，必须通过刷新令牌获取新JWT，平衡安全性与用户体验，避免频繁登录。
2. 适配SPA长驻特性：SPA通常不会频繁刷新页面，用户可能长时间保持会话，JWT过期后若无刷新机制，会直接导致所有API请求失败，严重影响使用体验。

适配当前架构的刷新令牌实现方案 #

结合你现有的Cookie+JWT+XSRF防护体系，推荐以下落地方式：

1. 刷新令牌的存储与Cookie配置

• 登录成功时，除JWT_TOKEN和XSRF_TOKEN外，额外返回REFRESH_TOKEN Cookie，配置为HttpOnly、Secured、SameSite=Strict。建议JWT有效期设为15-30分钟，刷新令牌有效期设为7-30天（根据业务安全需求调整）。
• 后端存储刷新令牌的哈希值（禁止明文存储），关联用户ID、过期时间及设备标识（可选），支持主动注销时标记令牌失效。

2. 刷新接口的实现

• 提供POST /refresh接口，该接口需和其他API一样校验X-XSRF-TOKEN请求头与Cookie中的XSRF_TOKEN，避免CSRF攻击。
• 接口核心逻辑：
  1. 读取Cookie中的REFRESH_TOKEN，验证其有效性（是否存在于后端存储、是否过期、是否匹配当前用户）。
  2. 验证通过后，生成新的JWT_TOKEN（重置有效期）；可选生成新的REFRESH_TOKEN（滚动刷新机制，进一步降低令牌泄露风险）。
  3. 将新的令牌以Cookie形式返回给前端。

3. 前端刷新逻辑

• 在React中通过请求拦截器，监听API返回的401未授权响应，结合JWT的exp字段提前判断是否为JWT过期（或后端返回特定错误码标识）。
• 调用/refresh接口获取新令牌，成功后自动重试之前失败的请求；若刷新接口返回401（刷新令牌过期或失效），则跳转至登录页面。
• 注意：全程依赖HttpOnly Cookie存储令牌，禁止将JWT或刷新令牌存入localStorage/sessionStorage，避免XSS攻击风险。

4. 后端安全校验补充

• 新增刷新令牌校验逻辑，可在/refresh接口内单独实现，或添加专属过滤器。校验时需检查刷新令牌是否已被注销（如用户主动登出）。
• 可选支持单设备登录：用户在新设备登录时，标记旧设备的刷新令牌失效，避免多设备同时登录的安全风险。

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