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.

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.

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.