对跨网域登录进行碎片整理

Eiji Kitamura

现代企业架构通常跨多个不同的网域。 组织会为不同的功能维护专用环境，例如用于营销的 brand.example、用于核心产品的 service-app.example，以及用于客户服务的 support-portal.example。理想情况下，您希望在用户浏览这些属性时提供统一的单点登录体验。 但是，工程团队通常会使用临时技术集成这些网域，从而导致碎片化。这会破坏内置的浏览器凭据管理功能，导致密码管理工具自动填充流程中断，并阻碍通行密钥的采用。

跨多个 Web 属性的跨网域身份碎片化。

如果同一账号跨多个网域，用户必须识别出这些网域属于同一组织，并在登录时提供相同的凭据。在最糟糕的情况下，用户会创建重复账号或将密码泄露给钓鱼式攻击网站。

了解如何使用架构标准和解决方案（例如元数据、跨源 iframe、身份联合和子网域整合）来解决跨网域身份碎片化问题，并提供顺畅的用户体验。

常见解决方法

组织使用多种成熟的技术来维护跨网域体验。虽然这些方法很常见，但随着浏览器强制执行更严格的隐私边界和安全标准，它们面临着结构性障碍。

CORS 提取请求

当网域独立运行时，前端通常依赖于针对集中式身份验证 API 的跨源 fetch()请求，这些请求可以使用 跨源资源共享 (CORS) 安全地获得许可。由于浏览器通常会阻止或限制跨网站 Cookie，因此开发者可能会明确设计这些 API 以返回身份验证令牌（例如 JSON Web 令牌 (JWT)），而不是依赖于 JSON 载荷中的 Set-Cookie 标头。

账号数据库共享

如需在后端统一身份，而无需复杂的前端集成，您可以集中管理用户数据存储区。虽然多个网域针对同一数据库进行身份验证，但其前端登录体验仍然是分开的。 这会迫使用户记住在哪些网域中使用了相同的凭据，从而导致糟糕的用户体验。

不连贯登录的问题

虽然技术解决方法可能实现基本功能，但无法提供顺畅的体验。不连贯的登录流程会引入摩擦点，从而损害可用性和安全性。

密码管理工具碎片化

最大的摩擦点是密码管理工具的中断。密码管理工具会将存储的凭据绑定到注册凭据的特定来源。这会阻止浏览器在不同网域中提供自动填充功能，即使这些网域属于同一组织也是如此。

当用户从具有已保存凭据的网域过渡到组织中的新网域时，密码管理工具无法识别这种关系，也不会触发自动填充提示。这会造成手动输入摩擦。 用户必须查找凭据、重置密码或创建重复账号。

由于密码管理工具在这些属性中不可靠，用户可能会放弃使用这些网站的工具。相反，他们通常会创建安全性较低但容易记住的密码，以便在其他地方重复使用，这会降低组织的整体安全性。

钓鱼式攻击网关

这种中断充当钓鱼式攻击网关。密码管理工具拒绝在无法识别的网域中自动填充是一种主要的防御机制。通过要求用户在不同的网址上手动输入凭据，您无意中训练用户成为钓鱼式攻击的受害者。

通行密钥障碍

当您使用通行密钥时，摩擦会加剧。WebAuthn 的核心安全架构以加密方式将通行密钥严格绑定到指定的依赖方 ID (RP ID)。

这会创建一个“RP ID 陷阱”。在 brand.example 上注册的通行密钥无法在 service-app.example 上使用，因为浏览器会拒绝跨网域访问。为避免提示用户为每个网站注册不同的通行密钥，您必须将这些属性整合到一个 RP ID 中。

推荐方法

如需建立身份连续性，您必须放弃临时登录集成，并采用公认的架构标准：

• 使用元数据配置文件: 托管元数据文件（例如 Digital Asset Links 和相关来源请求）， 以建立加密信任链。这样一来，您就可以在不同的网域和移动应用之间无缝共享凭据和通行密钥。这种方法是一种低成本、无声的身份碎片化修复方案，无需对现有 Web 基础架构进行复杂的重新架构。
• 使用跨源 iframe：在依赖方中嵌入 集中式身份验证来源作为 iframe，以 在不同网站之间桥接已保存的凭据和通行密钥。这种方法使用权限政策和分区 Cookie，在通过 CSP 和跨文档消息传递保持严格的安全边界的同时，实现无缝的上下文登录体验。
• 遵循标准身份联合： 采用行业标准协议（例如 OpenID Connect），在专用身份提供方 (IdP) 网域中集中进行 身份验证。这会通过安全重定向来规范登录流程，使用可靠且可扩缩的第一方解决方案取代脆弱的集成。
• 整合子网域：过渡到 通用根域名下的子网域。这样一来，您就可以通过通配符 Cookie 实现无缝会话共享，并在整个可注册网域中保持通行密钥的连续性。许多密码管理工具都可以识别共享的根域名，并自动建议在相关子网域中使用已保存的凭据。

使用元数据配置文件

跨网域身份的主要挑战是已保存凭据的碎片化。密码管理工具会将不同的网域和应用视为完全隔离的实体，这会阻止它们将在一个属性中保存的凭据自动填充到另一个属性中。

如需解决碎片化问题，您可以配置密码管理工具的行为，而不是更改网站结构。通过托管特定的元数据配置文件，组织可以以加密方式断言不同的网域和应用属于同一组织。 这样一来，操作系统、浏览器和密码管理工具就可以识别这种关系，并自动桥接身份上下文，在您的属性之间共享密码和通行密钥。即使您的 Web 网域已整合，也需要使用这种方法与移动应用共享基于 Web 的密码和通行密钥。

使用两个不同的配置文件，确保涵盖不同的平台和生态系统：

• Android 和 Chrome 上的 Google 密码管理工具：在 /.well-known/assetlinks.json 中托管 Digital Asset Links (DAL) JSON 文件，以在组织的关联应用和 网站之间建立可验证的信任关系。这种信任支持应用上的深层链接和 无缝凭据共享， 即在 Web 上保存的密码会自动填充到关联的 网站中（不过，在多个 Web 网域之间共享通行密钥仍然 需要 相关来源请求）。 如需了解详情，请参阅 无缝凭据共享 指南。

• iOS 和 Safari 上的 Apple 密码：在 /.well-known/apple-app-site-association 中托管 Apple App Site Association (AASA) 文件，以建立在 iOS 应用和 Safari 之间桥接 Apple 密码状态所需的 加密信任链。如需支持第三方生态系统，您 可以使用众包代码库集中声明这些关联的网域 。 这样做可确保独立工具（例如明确提取此代码库的 1Password）也能识别共享的身份上下文。如需详细了解 Apple App Site Association，请参阅 支持关联的网域。

如需在不同的 Web 网域中启用通行密钥并解决通行密钥 障碍，开发者可以在 相关来源请求 (ROR) 文件托管在 /.well-known/webauthn。ROR 明确声明了获授权的网域，这些网域可以安全地共享同一通行密钥 RP ID。如需详细了解相关来源请求，请参阅使用相关来源请求在您的网站之间重复使用通行密钥。

• 优点：
  • 面向最终用户的后台修复： 它完全在后台运行，这会自动解决自动填充碎片化问题，并在操作系统或浏览器级别建立通行密钥连续性，而不会对用户体验进行任何可见的更改。
  • 实现简单： 这是一种低成本的解决方案，只需要托管静态 JSON 文件。它不需要后端重新架构或复杂的令牌交换逻辑。
  • 保留现有基础架构： 您可以显著改善跨网域体验，而无需更改品牌或整合网域。
• 缺点：
  • 平台限制： 平台通常会对 ROR 强制执行严格的限制。例如，Chrome 将单个 RP ID 限制为最多 5 个关联的 eTLD+1 标签。例如，example.co.uk 和 example.de 共享同一个 example eTLD+1 标签；不过， example-rewards.com 使用单独的 example-rewards 标签。如果您管理着大量或多样的网域组合，这些限制可能不够。
  • 运营延迟增加： 解析元数据文件需要额外的网络往返，这会在浏览器处理身份验证时增加延迟。

使用元数据配置文件启用凭据共享。

使用跨源 iframe

如果您因 ROR 网域限制而无法使用元数据配置文件方法，则跨源 iframe 元素提供了一种可靠且受标准支持的路径，可解决跨网域登录挑战。

通过在依赖方（例如 brand.example）中嵌入集中式身份验证来源（例如 auth.brand.example）作为 iframe，您可以与常规表单字段和现代 API 进行交互。对于密码，浏览器的凭据管理工具会将自动填充操作与 iframe 的来源 (auth.example) 相关联。这样一来，用户就可以在不同的网站之间无缝访问其集中式凭据。

对于通行密钥，父窗口必须使用 权限政策 框架授予 iframe 访问权限，使 iframe 能够调用 WebAuthn 以针对其 自身来源的 RP ID 进行身份验证。在这两个流程中， CSP（内容安全政策）都可用于保护 用户免受点击劫持和跨网站脚本等攻击。身份验证成功后，系统会使用 分区 Cookie 建立会话，并使用 postMessage()将令牌安全地传输回父窗口。

• 优点：
  • 集中式凭据： 避免凭据碎片化。单个集中式来源管理已保存的密码和统一的通行密钥 RP ID，允许不同的网域共享这些凭据，而无需整合网域。
  • 上下文身份验证： 整个登录流程（无论是自动填充密码还是使用通行密钥进行验证）都在父页面中无缝地进行，避免了破坏性的联合重定向。
  • 对跟踪保护具有弹性： 即使在使用 分区 Cookie 的严格跨网站跟踪保护下，此方法也能 正常运行。
• 缺点：
  • 实现限制： 此架构需要专业的工程技术。它需要严格的 CSP (frame-ancestors)，以将嵌入限制为受信任的父网域并防止点击劫持；需要配置 HTTP 权限政策以启用 WebAuthn API；需要安全且经过验证的跨文档消息传递 (postMessage())，以缓解来源欺骗和 CSRF 攻击。如需了解最佳实践，请参阅 iframe 中的通行密钥。

跨源 iframe 身份验证流程。

遵循标准身份联合

采用标准身份联合（例如 OpenID Connect）是一种可靠且可持续的方法，可用于维护您的账号系统。 这种方法通过将身份验证工作流整合到单个专用身份提供方 (IdP) 网域（例如 auth.brand.example）来规范身份验证工作流。 借助已建立的协议，应用会将用户重定向到此中心枢纽进行身份验证，然后安全地接收令牌转移，以完成目标网域的登录。虽然标准联合通常与第三方登录 （例如“使用 Google 账号登录”）相关联，但它完全有效，并且作为第一方 解决方案广泛使用，以取代脆弱的解决方法。

• 优点：
  • 通用工程语言： 开发者无需学习或维护特定的自定义协议；他们可以依赖于已建立的行业知识和全面的库。此外，还有打包的解决方案。
  • 经过实战检验的可靠性： 标准协议经过验证，安全可靠，远比临时实现更可靠。
  • 易于扩展： 如果组织需要与新的第三方服务联合，或稍后集成收购，身份基础架构已准备好提供凭据。
  • 一致的用户体验： 用户会将集中式 IdP 页面识别为品牌的权威来源，从而明确何时何地需要凭据。
• 缺点：
  • 集成开销高： 开发或迁移到集中式 IdP 会带来较高的集成开销，并且需要专业的安全知识。组织必须投资安全地重构所有连接的应用，以支持基于安全重定向的模式。
  • 破坏性重定向： 身份验证流程需要将用户从来源网站重定向到集中式身份提供方页面，从而阻止无缝的上下文登录体验。

标准身份联合流程。

整合子网域

另一种结构性方法是将所有网域统一起来，方法是将不同的 数字属性移到 通用可注册根域名 (eTLD+1) 下。 这需要将单独的网域（例如 brand.example 和 service-app.example）转换为子网域（例如 www.brand.example 和 service.brand.example）。

• 优点：
  • 统一的凭据管理： 密码管理工具可以识别根域名，并将所有子网域视为单个条目，从而消除重复提示和手动输入密码。
  • 通行密钥连续性： 开发者可以原生将通行密钥 RP ID 范围限定为可注册网域，从而立即在所有关联的子网域中扩展通行密钥支持。在这种情况下，brand.example 的 RP ID 将 在 www.brand.example 和 service.brand.example 中都有效。
  • 轻松共享会话： 整合网域结构可以使用通配符 Cookie（例如将 Cookie 范围限定为 Domain=brand.example）共享单个会话。
• 缺点：
  • 品牌塑造和迁移限制： 如果您的组织要求使用不同的顶级域名，此方法可能会施加潜在的品牌塑造限制。迁移很复杂，需要仔细管理 HTTP 重定向，并对旧版跨源配置进行广泛的修复。

将子网域整合到通用根域名下。

总结

如需实现身份连续性，您必须从临时登录集成过渡到已建立的身份验证标准。通过根据这些已建立的做法（例如联合、网域整合、iframe 或元数据）评估业务限制，您可以消除用户体验摩擦，并改善整个生态系统中的身份验证。

如需详细了解相关主题，请务必 关注我们的博客，并在 Chrome 的身份门户 中探索更多资源。