The optimal account linking type for your Action is one that provides the
simplest experience for your users and fits the needs of your application or
business. Choosing your linking type is mostly dependent on the following
factors:

- Whether you want to allow account creation via voice
- Whether you want users to be able to sign in to your service with a non-Google account
- Whether or not your service can store confidential information (i.e., a client secret)

To figure out your ideal account linking type, follow these steps:

1. Consider the questions in the [Identify your preferred sign-in type](https://developers.google.com/assistant/identity/choose-type#identify_your_preferred_sign-in_type) section.
2. Consult the decision tree to choose your linking type.
3. Navigate to the section that corresponds to the initial type you chose to further refine how it works.

## Identify your preferred sign-in type

Before you consult the decision tree, consider the following questions:

- **Do you expect all your users to have a Google account?**
  - If your Action only targets Assistant, then you can expect all your users to have a Google account. If your Action targets platforms beyond Assistant, you cannot expect all your users to have a Google account.
  - If your service already has existing users, it's likely that some don't have a Google account or didn't sign into your service with a Google account.
- **If you have an OAuth implementation, can it be extended to support Google
  protocol?**
  - To support Google protocol, you need to be able to add the `intent=get` and `intent=create` functionality to your token exchange endpoint. This functionality allows Google to check if the user already exists in your backend and make a request to create a new account on your service, respectively.

Follow the decision tree below to identify the account linking type that's
optimal for you and your users:

![](https://developers.google.com/static/assistant/identity/images/decision-tree.png)

Once you select a linking type, continue to the corresponding section
below to learn more about how it works and make further decisions about how
account linking works in your Action.

### OAuth-based Google Sign-in "Streamlined" linking

The Streamlined linking type adds Google Sign-in (GSI) on top of OAuth-based
account linking, which provides the benefits of GSI (for example, voice-based
linking for Google users) while also enabling account linking for users who
registered to your service with a non-Google account. This linking type is
especially advantageous for end users because it provides a low-friction flow
for Google users with a fallback for non-Google users. For more information
about how Streamlined linking works, see the
[OAuth-based Google Sign-in "Streamlined" linking concept guide](https://developers.google.com/assistant/identity/gsi-oauth-concept-guide).

#### Refine OAuth-based Google Sign-in "Streamlined" linking type

When you use the Streamlined linking type in your Action, you specify
the answers to the following questions in the Actions console to define how
it works:

1. **Do you want to enable voice account creation or only allow account
   creation on your website?**

   Generally, you should enable account creation via voice so that
   users on a non-screened device can create an account without having to
   transfer to another device. If you do not allow account creation via voice,
   Assistant opens the URL to the web site that you provided for user
   authentication and directs the user to a phone to continue the account
   linking flow.

   However, you should not allow account creation via voice if any of the
   following applies:
   1. *You need full control of the account creation flow.* For example, you may need to show your terms of service to the user during account creation or some other type of notice.
   2. *You want to ensure that users who already have an account with you
      sign in with that account.* For example, you may want users to continue using their existing accounts if you offer a loyalty program and don't want the user to lose the points accrued on their account.
2. **Do you want to use the authorization code flow or implicit flow?**

   The authorization code flow and implicit flow differ in that the
   authorization code flow requires a second endpoint, the *token exchange*
   endpoint. This endpoint uses *refresh tokens* to generate new, short-lived
   access tokens without prompting the user to sign in again.

   Conversely, if you use the implicit flow, you return a long-lived access
   token to Google that usually does not need to be re-generated. For more
   information about the authorization code and implicit flows, see the
   [OAuth-based Google Sign-In "Streamlined" linking concept guide](https://developers.google.com/assistant/identity/gsi-oauth-concept-guide).

   Google recommends using the **authorization code flow** in your Action
   because it is more secure. However, use the **implicit flow** instead if
   your service can't store confidential information (i.e., a client secret).
   For example, you must use the implicit flow for public clients like
   single-page applications (SPAs).

After considering these decision points, consult the following decision tree:

![](https://developers.google.com/static/assistant/identity/images/gsi-oauth-tree.png)

### Google Sign-in

With the Google Sign-in (GSI) linking type, your Action can request access to your user's Google
profile during a conversation and use the profile information to check if the
user exists in your service's backend. If the user doesn't exist, they can
create a new account in your system using their Google profile information.

For GSI, you must enable account creation via voice, which lets the user
complete the entire flow over voice. For more information about GSI, see the
[Google Sign-In concept guide](https://developers.google.com/assistant/identity/gsi-concept-guide).

### OAuth linking

With the OAuth linking type, the user signs in with the standard OAuth 2.0 flow.
The OAuth linking type supports two industry-standard OAuth 2.0 flows:
the *implicit* and *authorization* code flows.

Google does not recommend the OAuth linking type by itself because it requires transferring
the user from voice to screen to complete the sign-in process if the user is on
a non-screened device. You can consider using this flow if you have an existing
implementation of an OAuth 2.0 server, and you cannot extend the token exchange
endpoint to add support for Google's protocols for automatic linking and
account creation from an ID token. For more information, see the
[OAuth linking concept guide](https://developers.google.com/assistant/identity/oauth-concept-guide).

#### Refine the flow

When you use the OAuth linking type in your Action, you must
specify the answer to the following question in the Actions console to define
how it works:

1. **Do you want to use the authorization code flow or implicit flow?**

   The OAuth linking type supports two industry-standard OAuth 2.0 flows:
   the *implicit* and *authorization* code flows. The authorization code flow
   and implicit flow differ in that the authorization code flow requires a
   second endpoint, the *token exchange* endpoint. This endpoint uses
   *refresh tokens* to generate new, short-lived access tokens without prompting
   the user to sign in again.

   Conversely, if you use the implicit flow, you return a long-lived access
   token to Google that usually does not need to be re-generated. For more
   information about the authorization code and implicit flows, see the
   [OAuth linking concept guide](https://developers.google.com/assistant/identity/oauth-concept-guide).

   Google recommends using the **authorization code flow** in your Action
   because it is more secure. However, use the **implicit flow** instead if
   your service can't store confidential information (i.e., a client secret).
   For example, you must use the implicit flow for public clients like
   single-page applications (SPAs).