Overview

Account linking enables Google Account holders to quickly, seamlessly and safely connect to your services. You may choose to implement Google Account Linking to share a user's data from your platform with Google apps and services.

The secure OAuth 2.0 protocol lets you safely link a user's Google Account with their account on your platform, thereby granting Google applications and devices access to your services.

Users can link or unlink their accounts and optionally create a new account on your platform with Google Account Linking.

Use cases

Some of the reasons to implement Google Account Linking are:

• Share a user's data from your platform with Google apps and services.

• Play your video and movie content using Google TV.

• Manage and control Google Smart Home connected devices using the Google Home app and Google Assistant, "Hey Google turn on the lights".

• Create user customized Google Assistant experiences and functionality with Conversational Actions, "Hey Google, order my usual from Starbucks".

• Enable users to earn rewards by viewing eligible live streams on YouTube after linking their Google Account to a rewards partner account.

• Pre-populate new accounts during sign-up with consensually shared data from a Google Account profile.

Supported features

These features are supported by Google Account Linking:

• Quickly and easily share your data using the OAuth Linking implicit flow.

• Provide improved security with the OAuth Linking authorization code flow.

• Sign-in existing users or sign-up new Google verified users to your platform, obtain their consent and securely share data with Streamlined linking.

• Reduce friction with App Flip. From a trusted Google app, one tap securely opens your verified Android or iOS app and one tap grants user consent and links accounts.

• Improve user privacy by defining custom scopes to share only necessary data, increase user trust by clearly defining how their data is used.

• Access to data and services hosted on your platform can be revoked by unlinking accounts. Implementing an optional token revocation endpoint lets you stay in sync with Google initiated events, while Cross-Account Protection (RISC) allows you to notify Google of any unlinking events that take place on your platform.

Note: Most of the OAuth 2.0 documentation for The Google Identity Platform covers how you can sign in your users with their Google Accounts and get authorization to call Google APIs on their behalf. Google Account Linking covers the reverse case of allowing the user of a Google service to authenticate with your platform and call your service's APIs. If you want to use OAuth 2.0 to access Google APIs, see the OAuth 2.0 client documentation.

Account linking flows

There are 3 Google Account Linking flows all of which are OAuth based and require you to manage or control OAuth 2.0 compliant authorization and token exchange endpoints.

During the linking process, you issue access tokens to Google for individual Google Accounts after obtaining account holders consent to link their accounts and share data.

OAuth Linking ('Web OAuth')

This is the basic OAuth flow that sends users to your website for linking. The user is redirected to your website to sign in to their account. Once signed in, the user consents to sharing their data, on your service, with Google. At that point, the user's Google Account and your service, are linked.

OAuth Linking supports the authorization code and implicit OAuth flows. Your service must host an OAuth 2.0 compliant authorization endpoint for the implicit flow, and must expose both an authorization and token exchange endpoint when using the authorization code flow.

Note: Implementing Web OAuth is required for all account linking integrations, as it is the fallback method for App Flip and Streamlined flows.

Figure 1. Account Linking on a user's phone with Web OAuth

OAuth-based App Flip Linking ('App Flip')

An OAuth flow that sends users to your app for linking.

OAuth-based App Flip Linking guides users as they move between your verified Android or iOS mobile apps and Google's platform to review the proposed data access changes and grant their consent to link their account on your platform with their Google account. To enable App Flip your service must support OAuth Linking or OAuth-based Google Sign-in Linking using the authorization code flow.

App Flip is supported for both Android and iOS.

How it works:

Google app checks if your app is installed on the user's device:

• If the app is found, the user is ‘flipped’ to your app. Your app gathers consent from the user to link the account with Google, and then 'flips back' to the Google surface.
• If app is not found or an error occurs during the app flip linking process, the user is redirected to Streamlined or Web OAuth flow.

Figure 2. Account Linking on a user's phone with App Flip

OAuth-based Streamlined Linking ('Streamlined')

OAuth-based Google Sign-In Streamlined linking adds Google Sign-In on top of OAuth linking, enabling users to complete linking the linking process without leaving the Google surface, thereby reducing frictions and drop-offs. OAuth-based Streamlined Linking offers the best user experience with seamless sign-in, account creation and account linking by combining Google Sign-in with OAuth linking. Your service must support OAuth 2.0 compliant authorization and token exchange endpoints. Additionally, your token exchange endpoint must support JSON Web Token (JWT) assertions and implement the check, create, and get, intents.

Note: The user never leaves the Google surface during this flow, so Google must show consent on behalf of the 3P in order for the flow to work properly.

How it works:

Google asserts the user account and passes this information to you:

• If an account exists for the user in your database, the user successfully links their Google account with their account on your service.
• if no account exists for the user in your database, the user can either create a new 3P account with the asserted information Google provides : email, name, and profile picture, or choose to sign in and link with another email (this will require them to sign-in to the your service via Web OAuth).

Figure 3. Account Linking on a user's phone with Streamlined Linking

Which flow should you use?

We recommend implementing all flows to ensure users get the best linking experience. The Streamlined and App flip flows reduce linking friction as users are able to complete the linking process in very few steps. The Web OAuth linking has the lowest level of effort and is a good place to start after which you can add on the other linking flows.

Note: The Web OAuth flow is required for all integrations as it is the fall back for the other flows.

Working with tokens

Google Account Linking is based upon the OAuth 2.0 industry standard.

You issue access tokens to Google for individual Google Accounts after obtaining account holders consent to link their accounts and share data.

代币类型

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. 将令牌生存期降低到正常水平。

Registering with Google

We'll need details of your OAuth 2.0 setup and to share credentials to enable account linking. See registration for details.