概览

帐号关联后，Google 帐号持有人可以快速、顺畅、安全地连接到您的服务。您可以选择实现 Google 账号关联，以与 Google 应用和服务共享您平台中的用户数据。

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

用户可以关联或解除关联帐号，还可以选择使用 Google 帐号关联功能在您的平台上创建新帐号。

用例

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

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

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

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

• 使用对话型 Action“Hey Google，从星巴克照常订餐”，打造用户自定义的 Google 助理体验和功能。

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

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

支持的功能

Google 账号关联功能支持以下功能：

• 使用 OAuth 链接隐式流程快速轻松地共享您的数据。

• 通过 OAuth 关联授权代码流程提高安全性。

• 让现有用户登录或注册已经过 Google 验证的新用户到您的平台，征得他们的同意，然后利用简化的关联功能安全地共享数据。

• 通过 App Flip 提供更顺畅的体验。在可信的 Google 应用中，只需点按一下即可安全地打开经过验证的 Android 或 iOS 应用，再点按一次即可表示同意并关联帐号。

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

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

注意：Google Identity Platform 的 OAuth 2.0 文档的大部分内容介绍了如何使用用户的 Google 帐号登录，并获得授权以代表用户调用 Google API。“Google 账号关联”涵盖允许 Google 服务用户向您的平台进行身份验证并调用您的服务的 API 的反向操作。如果您想使用 OAuth 2.0 访问 Google API，请参阅 OAuth 2.0 客户端文档。

账号关联流程

共有 3 个 Google 帐号关联流程，所有这些流程都基于 OAuth，并要求您管理或控制符合 OAuth 2.0 要求的授权和令牌交换端点。

在关联过程中，您需要先征得帐号持有人同意才能关联帐号并共享数据，然后再向 Google 颁发各个 Google 帐号的访问令牌。

OAuth 关联（“网络 OAuth”）

这是将用户转到您的网站以进行关联的基本 OAuth 流程。用户被重定向到您的网站以登录其帐号。登录后，用户即同意在您的服务中与 Google 分享其数据。完成上述操作后，用户的 Google 帐号便会与您的服务建立关联。

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

注意 ：所有帐号关联集成都需要实现网站 OAuth，因为这是 App Flip 和简化流程的后备方法。

图 1. 使用网络 OAuth 在用户手机上进行帐号关联

基于 OAuth 的 App Flip 链接（“App Flip”）

一种 OAuth 流程，可将用户转到您的应用以进行关联。

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

Android 和 iOS 均支持 App Flip。

运作方式：

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

• 如果找到应用，用户便会“翻转”到您的应用。您的应用在征求用户意见后会将帐号与 Google 关联，然后再从“翻转”回 Google surface。
• 如果未找到应用或在 App flip 关联过程中出现错误，用户会被重定向到简化版或网络版 OAuth 流程。

图 2. 使用 App Flip 在用户手机上进行账号关联

基于 OAuth 的简化链接（“简化”）

基于 OAuth 的 Google 登录简化型关联可在 OAuth 关联的基础上添加 Google 登录功能，使用户无需离开 Google 界面即可完成关联流程，从而减少阻力和流失情况。基于 OAuth 的简化关联将 Google 登录与 OAuth 关联相结合，通过无缝登录、帐号创建和帐号关联提供最佳用户体验。您的服务必须支持符合 OAuth 2.0 规范的授权和令牌交换端点。此外，您的令牌交换端点必须支持 JSON 网络令牌 (JWT) 断言，并实现 check、create 和 get intent。

注意 ：在此过程中，用户绝不会离开 Google surface，因此 Google 必须代表第三方表示同意，才能使相应流程正常运行。

运作方式：

Google 会声明该用户账号，并将此信息传递给您：

• 如果数据库中已有该用户的帐号，则表示该用户已成功将其 Google 帐号与其在您的服务中的帐号相关联。
• 如果您的数据库中没有该用户的帐号，该用户就可以使用声明的 Google 提供的信息（电子邮件地址、姓名和个人资料照片）创建一个新的第三方帐号，或者选择登录并与其他电子邮件地址关联（这需要用户通过网络 OAuth 登录您的服务）。

图 3. 通过精简关联功能在用户手机上进行帐号关联

您应该使用哪种流程？

我们建议您实现所有流程，以确保用户获得最佳关联体验。精简流程和应用翻转流程可以减少关联障碍，因为用户只需几步就能完成关联流程。使用 Web OAuth 关联耗时最少，您可以开始添加其他关联流程。

注意 ：所有集成都需要使用 Web 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.

向 Google 注册

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