Axios配置withCredentials:true后浏览器不发送凭证返回未认证错误

Postman作为独立HTTP客户端不受浏览器同源安全策略限制，会默认携带对应域下存储的所有Cookie，因此调用正常；浏览器环境下跨域请求带Cookie有严格的规则约束，任意环节不满足都会导致Cookie（即存取的accessToken）不会被携带到请求里，触发未认证报错，常见触发原因如下：

• 服务端CORS配置不符合带凭证请求的要求
  浏览器对开启withCredentials: true的跨域请求有强制校验规则，任意一条不满足都会拦截Cookie传输：
  1. Access-Control-Allow-Origin响应头不能设为通配符*，必须精确匹配请求来源的完整域名
  2. 必须返回Access-Control-Allow-Credentials: true响应头，缺省状态下浏览器不会向跨域接口传递Cookie
  3. Access-Control-Allow-Headers、Access-Control-Allow-Methods响应头也不能使用通配符*，必须明确列出允许的请求头、请求方法
• 存储accessToken的Cookie属性配置不符合跨域携带规则
  1. 若前端和接口服务跨站部署，Cookie的SameSite属性如果设为Strict或浏览器默认的Lax，跨站请求时浏览器会自动拦截该Cookie不发送，跨站场景需要将SameSite设为None
  2. SameSite=None的Cookie必须同时开启Secure属性，仅允许HTTPS协议下传输，Heroku部署的服务为HTTPS环境，需要匹配该配置
  3. Cookie的Domain、Path配置错误，当前请求地址不在Cookie的生效范围内，也会导致Cookie不携带
• 预检OPTIONS请求未正确处理
  带凭证的跨域请求正式发送前，浏览器会自动发送OPTIONS方法的预检请求校验CORS规则，如果服务端将OPTIONS请求拦截进入鉴权逻辑返回401，或者未给OPTIONS请求返回正确的CORS响应头，会导致后续正式请求被拦截，无法携带凭证。

• 修复服务端CORS配置
  1. 维护请求来源白名单，包含本地开发前端地址、生产前端地址，接口收到请求后校验当前请求的Origin是否在白名单内，校验通过则将该Origin值写入Access-Control-Allow-Origin响应头，禁止使用通配符*
  2. 所有接口响应（包含OPTIONS预检请求）统一添加Access-Control-Allow-Credentials: true响应头
  3. 明确配置Access-Control-Allow-Methods为服务端实际支持的请求方法（如GET,POST,PUT,DELETE,OPTIONS），明确配置Access-Control-Allow-Headers为接口实际允许接收的请求头（如Content-Type,Authorization），禁止使用通配符
  4. 给OPTIONS请求配置单独放行规则，不进入鉴权逻辑，直接返回204状态码和正确的CORS响应头即可
• 调整Cookie属性配置
  1. 前后端跨站部署的生产环境，将存储accessToken的CookieSameSite属性设为None，同时开启Secure属性适配HTTPS传输
  2. 本地HTTP调试阶段，可临时将SameSite设为Lax、关闭Secure属性，或通过本地代理将接口转发到前端同域下，绕过跨域限制
  3. 核对Cookie的Domain、Path配置，确保接口请求地址落在Cookie的生效范围内
• 验证排查
  1. 打开浏览器开发者工具的Network面板，定位到报错的GET请求，查看Request Headers中的Cookie字段是否携带了accessToken，若未携带则优先排查上述CORS、Cookie配置问题
  2. 检查该请求的Response Headers是否返回了正确的CORS字段，同时查看浏览器Console面板是否存在CORS相关报错
  3. 若请求头中已正常携带accessToken仍报错，排查服务端Cookie解析中间件配置、鉴权逻辑中Cookie字段名读取是否正确。

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