概览

选择集成路径

选择最符合您需求的路径：

路径	适用场景	了解详情
通用商务协议 (UCP)	商家和零售商。	UCP 文档
标准账号关联	智能家居、电视和 YouTube。	文档

注意：这些集成途径是互补的。 如果您要实现 UCP，建议您同时查看UCP 身份关联指南（了解具体产品要求）和本文档（了解核心 OAuth 实现详情）。

账号关联功能可让 Google 账号持有者快速、顺畅且安全地连接到您的服务。您可以选择实现 Google 账号关联，以便将用户在您平台上的数据与 Google 应用和服务分享。

借助安全的 OAuth 2.0 协议，您可以安全地将用户的 Google 账号与其在您平台上的账号相关联，从而授予 Google 应用和设备对您服务的访问权限。

用户可以关联或解除关联账号，也可以视需要在您的平台上通过 Google 账号关联创建新账号。

使用场景

实现 Google 账号关联的一些原因如下：

• 与 Google 应用和服务共享您平台上的用户数据。

• 使用通用商务协议 (UCP) 与 Google 购物和 AI 平台（Google 搜索、Gemini）集成。

• 使用 Google TV 播放视频和电影内容。

• 使用 Google Home 应用和 Google 助理管理和控制 Google 智能家居关联的设备，例如说“Hey Google，开灯”。

• 借助对话 Action，打造用户自定义的 Google 助理体验和功能，例如“Hey Google，在 Starbucks 订购我常点的餐品”。

• 让用户在将 Google 账号与奖励合作伙伴账号相关联后，通过在 YouTube 上观看符合条件的直播来赢取奖励。

• 在注册期间，使用Google 账号个人资料中经用户同意分享的数据预先填充新账号。

功能和要求

下表定义了每种关联流程的支持情况和建议。

关联流程	标准功能	UCP 功能
App Flip	推荐	推荐
简化关联流程	推荐	推荐
OAuth 关联	必需（后备）	必需（后备）
OAuth 2.1	推荐	推荐

智能体式开发 (MCP 和 UCP)

大语言模型 (LLM) 和 AI 智能体需要进行可靠的身份验证才能访问用户数据。Google 账号关联支持以下新兴范式：

• Model Context Protocol (MCP)：GAL 充当安全握手。 智能体使用 OAuth 2.1 令牌安全地查询 MCP 服务器工具。

• 通用商务协议 (UCP)：使购物智能体能够安全地访问用户个人资料和支付向量。

• 通过定义自定义范围来仅共享必要的数据，从而提升用户隐私保护水平；通过明确定义用户数据的使用方式，提高用户信任度。

• 通过解除账号关联，可以撤消对您平台托管的数据和服务的访问权限。通过实现可选的令牌撤消端点，您可以与 Google 发起的事件保持同步，而通过跨账号保护 (RISC)，您可以将平台上发生的任何取消关联事件通知给 Google。

注意：Google Identity Platform 的大部分 OAuth 2.0 文档都介绍了如何让用户使用其 Google 账号登录，以及如何获取授权以代表用户调用 Google APIs。Google 账号关联涵盖了反向情况，即允许 Google 服务用户通过您的平台进行身份验证并调用您服务的 API。如果您想使用 OAuth 2.0 访问 Google API，请参阅 OAuth 2.0 客户端文档。

账号关联流程

Google 账号关联流程共有 3 种，全部基于 OAuth，并且要求您管理或控制符合 OAuth 2.0 标准的授权和令牌交换端点。

在账号关联过程中，您在征得账号持有人同意关联其账号并分享数据后，会向 Google 针对各个 Google 账号发放访问令牌。

OAuth 关联

这是将用户引导至您的网站以进行关联的 OAuth 关联流程。用户会被重定向到您的网站，以便登录其账号。 登录后，用户同意在您的服务中与 Google 分享其数据。此时，用户的 Google 账号与您的服务已关联。

OAuth 关联支持授权代码和隐式 OAuth 流程。您的服务必须托管符合 OAuth 2.0 标准的隐式流程授权端点，并且在使用授权代码流程时必须公开授权端点和令牌交换端点。

注意：对于 MCP、UCP 和代理驱动的流程，必须使用 OAuth 2.1，并且不支持隐式流程。请改用授权代码流程。

注意： 所有账号关联集成都需要实现 OAuth 关联，因为它是应用快速关联和简化流程的后备方法。

图 1. 在用户手机上通过 OAuth 关联进行账号关联

基于 OAuth 的应用快速关联（“应用快速关联”）

一种 OAuth 流程，可将用户引导至您的应用以进行关联。

基于 OAuth 的 App Flip 关联会在用户在经过验证的 Android 或 iOS 移动应用与 Google 平台之间切换时引导用户查看建议的数据访问权限变更，并授予用户同意，以将其在您的平台上的账号与其 Google 账号相关联。如需启用 app flip，您的服务必须使用授权代码流程支持 OAuth 关联或基于 OAuth 的“使用 Google 账号关联”。

应用翻转功能同时支持 Android 和 iOS。

运作方式：

Google 应用会检查您的应用是否已安装在用户的设备上：

• 如果找到该应用，用户会“翻转”到您的应用。您的应用会征得用户同意，以将账号与 Google 相关联，然后“翻转回”Google 界面。
• 如果找不到应用，或者在 app flip 账号关联过程 中发生错误，系统会将用户重定向到简化的关联流程或 OAuth 关联流程。

图 2. 在用户手机上使用应用翻转功能进行账号关联

基于 OAuth 的简化关联（“简化”）

基于 OAuth 的“使用 Google 账号登录”简化版账号关联在 OAuth 账号关联的基础上添加了“使用 Google 账号登录”功能，使用户无需离开 Google 平台即可完成账号关联过程，从而减少摩擦和用户流失。基于 OAuth 的精简关联通过将“使用 Google 账号登录”与 OAuth 关联相结合，提供顺畅的登录、账号创建和账号关联体验，从而实现最佳用户体验。您的服务必须支持符合 OAuth 2.0 标准的授权和令牌交换端点。此外，您的令牌交换端点必须支持 JSON Web 令牌 (JWT) 断言，并实现 check、create 和 get intent。

注意： 在此流程中，用户始终在 Google 界面中操作，因此 Google 必须代表第三方显示同意声明，才能使流程正常运行。

运作方式：

Google 会断言用户账号并将此信息传递给您：

• 如果您的数据库中存在该用户的账号，则用户会成功将其 Google 账号与您服务中的账号相关联。
• 如果您的数据库中不存在相应用户的账号，则该用户可以选择使用 Google 提供的断言信息（电子邮件地址、姓名和个人资料照片）创建新的第三方账号，也可以选择使用其他电子邮件地址登录并关联账号（这需要用户使用 OAuth 关联登录您的服务）。

图 3. 在用户手机上使用精简关联功能进行账号关联

您应该使用哪个流程？

我们建议您实现所有流程，以确保用户获得最佳的关联体验。简化的关联流程和 app flip 流程可减少关联障碍，因为用户只需极少的步骤即可完成账号关联过程。OAuth 关联流程所需的工作量最少，是您开始关联流程的好起点，之后您可以添加其他关联流程。

注意： 所有集成都需要 OAuth 关联流程，因为它是其他流程的后备方案。

使用令牌

Google 账号关联基于 OAuth 2.0 行业标准。

在征得账号持有人的同意以关联其账号并共享数据后，您会向 Google 针对各个 Google 账号发放访问令牌。

令牌类型

OAuth 2.0 使用称为令牌的字符串在用户代理、客户端应用和 OAuth 2.0 服务器之间进行通信。

在帐号关联期间，可以使用三种类型的 OAuth 2.0 令牌：

• 授权代码 。一种短期令牌，可以交换为访问令牌和刷新令牌。出于安全考虑，Google 会调用您的授权端点来获取一次性或短期代码。

• 访问令牌 。一种令牌，用于授予持有者对资源的访问权限。为了限制因丢失此令牌而可能造成的风险，此令牌的生命周期有限，通常会在大约一小时后过期。

• 刷新令牌 。一种长期令牌，当访问令牌过期时，可以交换为新的访问令牌。当您的服务与 Google 集成时，此令牌仅由 Google 存储和使用。Google 会调用您的令牌交换端点，以将刷新令牌交换为访问令牌，而访问令牌又用于访问用户数据。

令牌处理

在集群环境和客户端-服务器交换中，竞争条件可能会导致在使用令牌时出现复杂的时序和错误处理场景。 例如：

• 您收到有关新访问令牌的请求，并签发了新的访问令牌。同时，您收到有关使用之前未过期的访问令牌访问您服务资源的请求。
• Google 尚未收到（或永远不会收到）您的刷新令牌回复。与此同时，之前有效的刷新令牌在 Google 的请求中使用。

由于集群中运行的异步服务、网络行为或其他方式，请求和回复可能会以任何顺序到达，或者根本不会到达。

无法保证您的令牌处理系统和 Google 的令牌处理系统之间以及内部的即时且完全一致的共享状态。在短时间内，多个有效且未过期的令牌可能会在系统内或跨系统共存。为了最大限度地减少对用户的负面影响，我们建议您执行以下操作：

• 接受未过期的访问令牌，即使在签发新令牌后也是如此。
• 使用 刷新令牌轮替的替代方案。
• 支持多个同时有效的访问令牌和刷新令牌。出于安全考虑，您应限制令牌数量和令牌生命周期。

维护和服务中断处理

在维护期间或计划外中断期间，Google 可能无法调用您的授权端点或令牌交换端点来获取访问令牌和刷新令牌。

您的端点应返回 503 错误代码和空正文。在这种情况下，Google 会在有限的时间内重试失败的令牌交换请求。前提是 Google 稍后能够获取刷新令牌和访问令牌，否则用户将无法看到失败的请求。

**警告** ：请勿在维护或中断期间返回 400 错误代码和 {"error": "invalid_grant"} 正文 。这样做会删除之前签发的令牌，并要求用户重新关联其帐号。

如果用户发起的访问令牌请求失败，则会导致显示错误。如果使用隐式 OAuth 2.0 流程，则用户需要重试关联失败。

建议

有很多解决方案可以最大限度地减少维护影响。您可以考虑以下选项：

• 维护现有服务，并将有限数量的请求路由到新更新的服务。仅在确认预期功能后才迁移所有请求。

• 减少维护期间的令牌请求数量：

  • 将维护期限制为小于访问令牌生命周期。

  • 暂时延长访问令牌生命周期：

    1. 将令牌生命周期延长到大于维护期。
    2. 等待访问令牌生命周期的两倍时长，以便用户将短期令牌交换为长期令牌。
    3. 进入维护期。
    4. 使用 503 错误代码和空正文响应令牌请求。
    5. 退出维护期。
    6. 将令牌生命周期缩短回正常水平。

持久性关联

持久关联是实现稳定集成的一项核心要求。这样可确保即使在发生暂时性网络故障或定期刷新凭据期间，用户账号仍保持关联状态。

如需实现持久关联，请使用“滑动窗口”方法：延长现有刷新令牌的过期时间，而不是轮换刷新令牌（请参阅 RFC 6749 第 6 部分）。这样可以防止在 Google 已签发新的刷新令牌但未成功接收或存储该令牌时可能发生的竞态条件和意外取消关联。

使用 Google 账号注册

我们需要了解您的 OAuth 2.0 设置的详细信息，并共享凭据以启用账号关联。如需了解详情，请参阅注册。