Overview

Account linking enables Google Account holders to quickly, seamlessly and safely connect to your 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 your platform's individualized account data with Google apps and devices.

• 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.

How it works

OAuth 2.0 standard linking flows

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 Linking supports the authorization code and implicit 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.

Streamlined user experience

OAuth-based Google Sign-in 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.

OAuth-based App Flip Linking guides users as they move between your verified Android and 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.

Working with tokens

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.