概览

选择集成路径

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

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

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

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

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

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

使用场景

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

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

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

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

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

• 使用 对话型 Action创建用户自定义的 Google 助理体验和功能， 例如“Hey Google，从星巴克订购我常点的东西”。

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

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

功能和要求

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

关联流程	标准功能	UCP 功能
应用快速关联	推荐	推荐
简化关联	推荐	推荐
OAuth 关联	必需（后备）	必需（后备）
OAuth 2.1	推荐	推荐

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

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

注意： Google 身份平台的大部分 OAuth 2.0 文档都介绍了如何让用户使用其 Google 账号登录，以及如何获取授权以代表用户调用 Google API。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 的应用快速关联可引导用户在您的已验证 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 账号的访问令牌。

Token types

OAuth 2.0 uses strings called tokens to communicate between the user agent, the client application, and the OAuth 2.0 server.

Three types of OAuth 2.0 tokens can be used during account linking:

• Authorization code. A short-lived token that can be exchanged for an access and a refresh token. For security purposes, Google calls your authorization endpoint to obtain a single use or very short-lived code.

• Access token. A token that grants the bearer access to a resource. To limit exposure that could result from the loss of this token, it has a limited lifetime, usually expiring after an hour or so.

• Refresh token. A long-lived token that can be exchanged for a new access token when an access token expires. When your service integrates with Google, this token is exclusively stored and used by Google. Google calls your token exchange endpoint to exchange refresh tokens for access tokens, which are in turn used to access user data.

Token handling

Race conditions in clustered environments and client-server exchanges can result in complex timing and error handling scenarios when working with tokens. For example:

• You receive a request for a new access token, and you issue a new access token. Concurrently, you receive a request for access to your service's resource using the previous, unexpired access token.
• Your refresh token reply is yet to be received (or is never received) by Google. Meanwhile, the previously valid refresh token is used in a request from Google.

Requests and replies can arrive in any order, or not at all due to asynchronous services running in a cluster, network behavior, or other means.

Immediate and fully consistent shared state both within, and between, your and Google's token handling systems cannot be guaranteed. Multiple valid, unexpired tokens can coexist within or across systems short period of time. To minimize negative user impact we recommend you do the following:

• Accept unexpired access tokens, even after a newer token is issued.
• Use alternatives to Refresh Token Rotation.
• Support multiple, concurrently valid access and refresh tokens. For security, you should limit the number of tokens and token lifetime.

Maintenance and outage handling

During maintenance or unplanned outages Google might be unable to call your authorization or token exchange endpoints to obtain access and refresh tokens.

Your endpoints should respond with a 503 error code and empty body. In this case, Google retries failed token exchange requests for a limited time. Provided that Google is later able to obtain refresh and access tokens, failed requests are not visible to users.

Warning: Do not return a 400 error code and {"error": "invalid_grant"} body during maintenance or outages. Doing so deletes previously issued tokens and requires users to relink their accounts.

Failing requests for an access token result in a visible error, if initiated by a user. Users will be required to retry linking failures if the implicit OAuth 2.0 flow is used.

Recommendations

There are many solutions to minimize maintenance impact. Some options to consider:

• Maintain your existing service and route a limited number of requests to your newly updated service. Migrate all requests only after confirming expected functionality.

• Reduce the number of token requests during the maintenance period:

  • Limit maintenance periods to less than the access token lifetime.

  • Temporarily increase the access token lifetime:

    1. Increase token lifetime to greater than maintenance period.
    2. Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
    3. Enter maintenance.
    4. Respond to token requests with a 503 error code and empty body.
    5. Exit maintenance.
    6. Decrease token lifetime back to normal.

持久关联

持久关联是稳定集成的核心要求。它可确保用户账号即使在网络暂时出现故障或凭据定期刷新期间仍保持关联状态。

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

向 Google 注册

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