如何避免同一认证服务器下不同Web应用共享身份认证Cookie

你对Cookie作用域的认知是正确的：要让api.company.com接收到Cookie，Cookie的Domain属性只能设置为api.company.com本身或父域company.com，设置为spa1.company.com/spa2.company.com时跨子域请求不会携带，无法满足认证需求。以下是3种可落地的标准化解决方案，按推荐优先级排序：

方案1：OAuth2.0客户端路径隔离（行业标准推荐） #

这是多客户端共享统一认证接口的通用标准化实现，完全符合Cookie规范，安全性无损耗：

• 给两个SPA分别分配独立的客户端标识，比如spa1、spa2
• 调整两个SPA的认证接口调用路径，增加客户端标识前缀：
  • spa1调用api.company.com/spa1/authenticate
  • spa2调用api.company.com/spa2/authenticate
• 服务端返回认证Cookie时，将Path属性分别设置为/spa1/authenticate、/spa2/authenticate
• 浏览器会根据请求路径自动匹配携带对应Cookie，两个Cookie完全独立，不会互相覆盖也不会被错误携带

方案2：Cookie名称按来源区分（兼容现有路径） #

如果不想调整现有认证接口的路径规则，可以用这个低改动方案：

• 服务端接收认证请求时，校验请求的Origin头，判断请求来自spa1.company.com还是spa2.company.com
• 下发Cookie时，按来源给Cookie名称加标识，比如auth_token_spa1、auth_token_spa2
• 认证接口逻辑适配：根据请求的Origin读取对应名称的Cookie做身份校验即可
• 注意必须严格校验Origin头防止伪造请求，原有的httponly/secure/samesite=strict安全属性全部保留，安全性不受影响

方案3：网关层无侵入适配 #

如果不想改动SPA和认证服务的业务代码，可以在API网关层做统一处理：

• 网关识别请求的Referer或Origin头，判断请求来源是哪个SPA
• 将发往api.company.com/authenticate的请求自动重写到对应前缀的路径，比如来源是spa1就重写为/spa1/authenticate
• 认证服务按路径前缀返回对应Path的Cookie即可，前端和后端业务逻辑都不需要改动

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