Google Account Linking overview

Google Account Linking enables users to quickly, seamlessly, and securely connect to your services using their Google identity.

The secure OAuth 2.0 protocol lets you safely link a Google Account for a user to their user account on your platform. This grants Google users and applications access to your services.

Users can link or unlink their accounts, and optionally create a user account on your platform using Google Account Linking.

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.

OAuth 2.0 standard linking flows

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

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

Unlinking

Access to your data and services can be revoked by unlinking accounts. Unlinking by user request, or other means can occur from your platform or Google.

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.