SPA中JWT的Access Token与Refresh Token是否应一同传输？

当前配置的合理性分析 #

首先，用httpOnly+secure Cookie存储令牌的方向是对的——这能避免XSS攻击直接窃取令牌，因为JS无法读取httpOnly Cookie。但同时把Access Token和Refresh Token放在同一个Cookie（或两个Cookie但每次请求都一起发送）的做法确实存在严重风险：一旦Cookie被中间人拦截（secure要求HTTPS能降低风险，但无法完全杜绝），攻击者拿到Refresh Token后就能不断请求刷新接口获取新的Access Token，相当于长期拥有用户权限，这个配置显然不合理。

让两类令牌不同时传输的Cookie方案 #

有两种可行思路：

• 路径隔离Cookie：
  把Refresh Token单独存在一个httpOnly+secure+SameSite=Strict的Cookie里，设置Path=/api/refresh——这样只有请求刷新令牌的接口时，浏览器才会发送这个Refresh Token Cookie。
  Access Token则存在另一个httpOnly+secure的Cookie里，设置Path=/api，只有访问业务API时才会携带，平时不会和Refresh Token一起传输。
• 内存存Access Token，Cookie存Refresh Token：
  SPA中把Access Token存在内存（比如Vuex、Redux或全局变量），只把Refresh Token存在httpOnly Cookie里。正常请求用内存中的Access Token（放在请求头Authorization: Bearer xxx），只有当Access Token过期时才调用刷新接口，此时浏览器自动携带Refresh Token Cookie。这种方式下两个令牌永远不会同时出现在同一次请求中，彻底避免同时被拦截的风险。

更安全的SPA存储JWT令牌方案 #

除了上面的优化，还有几个更完善的方案：

• 优先使用PKCE授权码流程：
  对于SPA，OAuth2的PKCE（授权码+证明密钥交换）流程比隐式流程安全得多。后端返回短期的Access Token和长期的Refresh Token，Access Token存在内存，Refresh Token存在httpOnly Cookie，结合SameSite和CSRF令牌防护CSRF攻击。
• 缩短Access Token生命周期：
  把Access Token的有效期设置得尽可能短（比如15分钟以内），就算不幸被拦截，攻击者能利用的窗口也很小，大幅降低风险。
• 添加额外验证维度：
  生成令牌时加入用户代理（User-Agent）哈希、IP地址（谨慎使用，IP可能动态变化）等信息，后端验证令牌时校验这些信息，就算令牌被拦截，攻击者的环境不匹配也无法使用。

内容的提问来源于stack exchange，提问作者B. Sebastiano