2023年跨域Cookie与JWT认证疑问：前后端分离架构下的困惑

1. 是否所有认证方案都需要后端发送Cookie？ #

不是，不同认证方案的处理逻辑差异很大：

• 传统Cookie认证：必须依赖后端通过Set-Cookie响应头发送Cookie，由浏览器自动管理，后续请求会自动携带。但跨域场景下需满足SameSite、Secure、Domain等Cookie属性配置，同时后端要配合设置CORS的Access-Control-Allow-Credentials: true，否则浏览器会拦截跨域Cookie。
• 纯JWT无Cookie方案：后端可直接将access token和refresh token以JSON响应体返回，前端自行存储在localStorage或sessionStorage中，后续请求手动在Authorization头中携带Bearer <token>。这种方案完全不需要Cookie，自然不存在跨域Cookie拦截问题，但要注意防范XSS攻击。
• JWT+Cookie混合方案：即你了解的用Cookie存储refresh token的方式，此时后端需通过Set-Cookie头将refresh token写入浏览器的httponly Cookie（前端无法读取，可防范XSS），而access token仍以JSON形式返回给前端存储在内存或localStorage中。这种方案仅需后端发送refresh token对应的Cookie，access token无需通过Cookie传递。

2. JWT方案中refresh token的存储逻辑 #

主流推荐的方式是后端通过Set-Cookie头直接设置带httponly属性的refresh token，而非返回JSON让前端存储：

• 前端无法操作httponly Cookie，能有效避免XSS攻击窃取refresh token；
• 若后端返回JSON格式的refresh token，前端无法通过JS设置httponly属性（浏览器禁止JS操作该类型Cookie），也就失去了用httponly Cookie的安全价值。

跨域场景补充说明 #

如果采用JWT+Cookie混合方案，后端必须做好以下配置：

• Cookie的SameSite属性设为None（跨域场景必填），同时添加Secure属性（仅允许HTTPS传输）；
• CORS配置中开启Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能设为*，必须指定前端的具体域名。

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