Overview (original) (raw)

Choose your integration path

Select the path that best suits your needs:

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.
• Integrate with Google Shopping and AI surfaces (Search, Gemini) using theUniversal Commerce Protocol (UCP).
• Play your video and movie content using Google TV.
• Manage and control Google Smart Homeconnected devices using the Google Home app and Google Assistant, "Hey Google turn on the lights".
• Create user customized Google Assistant experiences and functionality withConversational 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 arewards 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 share your data using theOAuth Linking implicit flow.
• Provide improved security with theOAuth 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 withStreamlined 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 byunlinking accounts. Implementing an optionaltoken revocation endpointlets you stay in sync with Google initiated events, while Cross-Account Protection (RISC)lets you notify Google of any unlinking events that take place on your platform.

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.

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 orOAuth-based Sign in with Google Linkingusing 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 Sign in with Google Streamlined linking adds Sign in with Google 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 Linkingoffers the best user experience with seamless sign-in, account creation and account linking by combining Sign in with Google with OAuth linking. Your service must support OAuth 2.0 compliant authorization and token exchange endpoints. Additionally, your token exchange endpoint must supportJSON Web Token (JWT) assertions and implement thecheck,create, and get, intents.

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

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

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.

Register with Google

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