为何存储JWT到Cookie会引发CORS问题，用Authorization头却不会？

jwt.io里那句“若令牌通过Authorization头发送，跨源资源共享（CORS）不会成为问题，因为它不使用Cookie”的真实意思，不是说完全不需要配置CORS，而是指这种方式避免了Cookie带来的额外CORS限制和浏览器拦截问题，让跨源授权的实现更简单。

核心差异对比 #

1. CORS配置的复杂度不同 #

• 用Cookie存储JWT时：
  • 前端发起跨源请求必须设置withCredentials: true（比如Axios等请求库的对应配置）
  • 服务器必须同时配置两个关键响应头：
    • Access-Control-Allow-Credentials: true（也就是你提到的Spring中configuration.setAllowCredentials(true);对应的配置）
    • Access-Control-Allow-Origin不能设为*，必须指定具体的请求源（比如https://your-frontend-domain.com），否则浏览器会直接拒绝响应
• 用Authorization头（比如Bearer Token）时：
  • 不需要设置withCredentials，也不需要服务器返回Access-Control-Allow-Credentials
  • 服务器的Access-Control-Allow-Origin可以设为*（生产环境不推荐，但技术上允许），只要配置好允许的请求方法和头即可

2. 浏览器的Cookie拦截机制 #

• Cookie受SameSite策略约束：现代浏览器默认SameSite为Lax，跨站请求（比如从a.com请求b.com）会自动阻止携带Cookie，就算配置了正确的CORS也没用，必须额外设置Cookie的SameSite属性为None（同时还要加Secure属性，要求HTTPS环境）
• Authorization头不受SameSite限制：只要是合法的跨源请求，浏览器都会正常携带这个头，不会被拦截

3. 第三方Cookie的限制 #

现在主流浏览器（比如Safari、Chrome）对第三方Cookie有严格的拦截政策，跨站场景下Cookie可能被浏览器直接屏蔽，导致JWT无法传递。而Authorization头是请求头的一部分，不属于Cookie范畴，不会被当作第三方Cookie拦截。

总结 #

jwt.io的表述其实是在强调：用Authorization头传递JWT，避开了Cookie在跨源场景下的各种额外限制和浏览器拦截问题，相比用Cookie存储JWT，CORS相关的配置和踩坑点要少得多，所以说“不会成为问题”——当然基础的CORS配置还是需要的，只是没有Cookie带来的额外麻烦。

内容的提问来源于stack exchange，提问作者Chang Hyeon Kim