如何在无第三方Cookie的情况下实现跨域OIDC OAuth认证？

针对多域名产品的集中认证需求，在主流浏览器限制第三方Cookie的背景下，以下是几个可落地的解决思路，包括类似Google OneTap的实现方式：

1. 业务后端代理令牌刷新 #

• 放弃第三方Cookie存储刷新令牌的模式，改为让每个业务域名的后端持有刷新令牌：
  • 用户完成认证后，认证服务将授权码返回给业务后端，后端用授权码换取访问令牌和刷新令牌，刷新令牌仅存储在业务后端的安全存储（如加密数据库、缓存）中，不传递给前端。
  • 业务后端将短期访问令牌存入同站点的HttpOnly+Secure+SameSite=Lax Cookie，前端通过该Cookie发起业务请求，由后端验证令牌有效性。
  • 当访问令牌过期时，业务后端直接调用认证服务的刷新接口（携带自身存储的刷新令牌），获取新的访问令牌后更新前端的Cookie。
  • 优势：完全规避第三方Cookie限制，刷新令牌全程不接触前端，从根源降低XSS窃取风险。

2. SPA场景用Authorization Code Flow with PKCE #

• 针对纯前端单页应用，采用PKCE增强的授权码流程：
  • 前端生成随机的code_verifier和对应的code_challenge，发起授权请求到认证服务。
  • 认证完成后，前端拿到授权码，携带code_verifier向认证服务换取访问令牌和刷新令牌。
  • 访问令牌存入内存（避免持久化带来的XSS风险），刷新令牌加密后存入同站点HttpOnly Cookie，或由前端通过业务后端代理进行刷新操作（前端不直接持有刷新令牌）。
  • 核心：PKCE防止授权码被拦截，结合后端代理刷新令牌，平衡安全性和跨域需求。

3. 统一业务域名到认证服务的子域名下 #

• 如果所有业务产品可以调整为认证服务的子域名（例如认证域为auth.example.com，业务域为app1.example.com、app2.example.com），可直接使用同站点Cookie：
  • 认证服务设置Cookie的Domain=.example.com，同时开启HttpOnly+Secure+SameSite=Lax属性，所有子域名均可访问该Cookie。
  • 这是成本最低的方案，但前提是所有业务域名能统一到同一父域名下，适合有域名规划空间的企业。

4. 同域iframe+PostMessage跨域身份传递（Google OneTap核心逻辑） #

• Google OneTap的实现核心是利用认证服务域名的同域iframe绕过第三方Cookie限制：
  • 在业务页面中嵌入一个来自认证服务域名的隐藏iframe，该iframe属于认证服务同域，因此可以正常访问认证服务设置的HttpOnly同站点Cookie（存储刷新令牌）。
  • 业务页面通过postMessage向iframe发送身份验证或令牌刷新请求，iframe在认证服务域名下完成令牌刷新，获取新的访问令牌后，再通过postMessage将令牌传回业务页面（必须严格验证event.origin，仅处理可信业务域名的请求）。
  • 访问令牌设置较短有效期（如15分钟），降低泄露风险；业务页面拿到令牌后，存入同站点HttpOnly Cookie供后续请求使用。

5. 高安全场景用Token Binding或MTLS #

• 对安全性要求极高的场景，可采用绑定客户端身份的方案：
  • Token Binding：将令牌与客户端的TLS会话绑定，认证服务仅接受与特定TLS会话匹配的令牌，即使令牌被窃取也无法复用。此时访问令牌可存入前端，因为窃取后无法使用。
  • MTLS：客户端使用专属证书与认证服务建立TLS连接，认证服务通过证书验证客户端身份，结合短期访问令牌，无需依赖刷新令牌，每次请求都通过证书验证身份。
  • 缺点：部署成本较高，需要客户端管理证书，适合企业内部应用或高敏感业务场景。

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