跨不同子域共享JWT Cookie的技术方案咨询

1. 改用Authorization Header（最直接可行） #

这是适配你当前域名限制的最优方案，操作步骤清晰：

• 前端登录时，后端直接返回JWT字符串（无需通过Set-Cookie设置），前端将JWT存储在localStorage、sessionStorage或内存中
• 每次调用API时，手动在请求头添加Authorization: Bearer <你的JWT令牌>
• 后端从请求头提取JWT完成验证

注意：用localStorage存储存在XSS攻击风险，建议配合前端XSS防护策略（如内容安全策略CSP、输入过滤）；若追求更高安全性，可选择内存存储（页面刷新后需重新登录）。

2. 反向代理统一请求入口 #

如果不想大幅修改前端请求逻辑，可在前端部署的bar.example.com配置反向代理：

• 将前端所有API请求（如/api/*路径）转发至foo.example.com
• 此时前端请求均指向bar.example.com，Cookie会自动携带，代理转发时将Cookie传递给API服务

以Nginx配置为例：

location /api/ {
    proxy_pass https://foo.example.com/;
    proxy_set_header Cookie $http_cookie;
    proxy_set_header Host foo.example.com;
}

开发环境可通过webpack devServer的proxy配置实现，生产环境需确认共享主机是否支持反向代理功能。

3. 前端手动提取Cookie并携带 #

若后端仍需通过Set-Cookie返回JWT：

• 前端登录请求开启withCredentials: true，获取Cookie后通过document.cookie解析出JWT
• 后续API请求手动将JWT放入请求头（如Authorization Header）或请求参数中
• 后端从对应位置提取JWT完成验证

该方案本质与Authorization Header方案类似，只是JWT的获取方式从后端直接返回变为Cookie提取。

方案选择建议 #

优先采用Authorization Header方案，实现成本最低，完全规避Cookie跨域限制；若需保留现有请求逻辑，再考虑反向代理方案。

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