Choisir votre type d'association de comptes
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le type d'association de compte optimal pour votre action est celui qui offre l'expérience la plus simple à vos utilisateurs et qui répond aux besoins de votre application ou de votre entreprise. Le choix du type d'association dépend principalement des facteurs suivants:
- Autoriser ou non la création de comptes par commande vocale
- Indique si vous souhaitez que les utilisateurs puissent se connecter à votre service avec un compte autre que Google.
- Indique si votre service peut stocker des informations confidentielles (par exemple, un code secret de client).
Pour déterminer le type d'association de comptes idéal, procédez comme suit:
- Considérez les questions de la section Identifier votre type de connexion préféré.
- Consultez l'arbre de décision pour choisir votre type d'association.
- Accédez à la section qui correspond au type initial que vous avez choisi pour affiner davantage son fonctionnement.
Identifier votre type de connexion préféré
Avant de consulter l'arbre de décision, posez-vous les questions suivantes:
- Pensez-vous que tous vos utilisateurs possèdent un compte Google ?
- Si votre action ne cible que l'Assistant, tous vos utilisateurs doivent disposer d'un compte Google. Si votre action cible des plates-formes autres que l'Assistant, tous vos utilisateurs ne devraient pas avoir de compte Google.
- Si votre service compte déjà des utilisateurs, il est probable que certains ne possèdent pas de compte Google ou ne se soient pas connectés à votre service avec un compte Google.
- Si vous avez une implémentation OAuth, peut-elle être étendue pour assurer la compatibilité avec le protocole Google ?
- Pour prendre en charge le protocole Google, vous devez pouvoir ajouter les fonctionnalités
intent=get et intent=create au point de terminaison de votre échange de jetons. Cette fonctionnalité permet à Google de vérifier si l'utilisateur existe déjà dans votre backend et d'envoyer une requête pour créer un compte sur votre service, respectivement.
Suivez l'arbre de décision ci-dessous pour identifier le type d'association de comptes le plus adapté pour vous et vos utilisateurs:
Une fois que vous avez sélectionné un type d'association, passez à la section correspondante ci-dessous pour en savoir plus sur son fonctionnement et prendre d'autres décisions sur le fonctionnement de l'association de comptes dans votre action.
Association simplifiée avec Google Sign-In basée sur OAuth
Le type d'association simplifiée ajoute Google Sign-In (GSI) en plus de l'association de compte basée sur OAuth, ce qui offre les avantages des GSI (par exemple, l'association par commande vocale pour les utilisateurs Google) tout en permettant l'association de compte pour les utilisateurs qui se sont inscrits à votre service avec un compte autre que Google. Ce type d'association est particulièrement avantageux pour les utilisateurs finaux, car il fournit un flux simple aux utilisateurs de Google avec une solution de secours pour les utilisateurs autres que Google. Pour en savoir plus sur le fonctionnement de l'association simplifiée, consultez le Guide sur le concept d'association simplifiée basée sur le protocole OAuth de Google Sign-In.
Améliorer le type d'association "Simplifié" de Google Sign-In basé sur OAuth
Lorsque vous utilisez le type d'association simplifiée dans votre action, vous devez spécifier les réponses aux questions suivantes dans la console Actions pour en définir le fonctionnement:
Voulez-vous activer la création de comptes Voice ou n'autoriser que la création de comptes sur votre site Web ?
En règle générale, vous devez activer la création de compte par commande vocale afin que les utilisateurs d'un appareil non filtré puissent créer un compte sans avoir à le transférer vers un autre appareil. Si vous n'autorisez pas la création de comptes par commande vocale, l'Assistant ouvre l'URL du site Web que vous avez fourni pour l'authentification des utilisateurs et redirige l'utilisateur vers un téléphone pour poursuivre le flux d'association de compte.
Toutefois, vous ne devez pas autoriser la création de comptes par commande vocale dans les cas suivants:
- Vous devez avoir un contrôle total sur le processus de création de compte. Par exemple, vous devrez peut-être montrer vos conditions d'utilisation à l'utilisateur lors de la création du compte ou d'un autre type de notification.
- Vous voulez vous assurer que les utilisateurs qui possèdent déjà un compte chez vous se connectent avec ce compte. Par exemple, vous pouvez souhaiter que les utilisateurs continuent à utiliser leur compte existant si vous proposez un programme de fidélité et qu'ils ne perdent pas les points accumulés avec leur compte.
Voulez-vous utiliser le flux de code d'autorisation ou le flux implicite ?
Le flux de code d'autorisation et le flux implicite diffèrent dans la mesure où ils nécessitent un deuxième point de terminaison, le point de terminaison d'échange de jetons. Ce point de terminaison utilise des jetons d'actualisation pour générer de nouveaux jetons d'accès de courte durée sans inviter l'utilisateur à se reconnecter.
À l'inverse, si vous utilisez le flux implicite, vous renvoyez à Google un jeton d'accès de longue durée qui n'a généralement pas besoin d'être généré de nouveau. Pour en savoir plus sur le code d'autorisation et les flux implicites, consultez le Guide sur le concept d'association simplifiée basée sur Google Sign-In basé sur le protocole OAuth.
Google vous recommande d'utiliser le flux de code d'autorisation dans votre action, car il est plus sécurisé. Toutefois, utilisez plutôt le flux implicite si votre service ne peut pas stocker d'informations confidentielles (c'est-à-dire un code secret de client).
Par exemple, vous devez utiliser le flux implicite pour les clients publics tels que les applications monopages (SPA).
Après avoir pris en compte ces points de décision, consultez l'arbre de décision suivant:
Google Sign-In
Avec le type d'association Google Sign-In (GSI), votre action peut demander l'accès au profil Google de votre utilisateur au cours d'une conversation et utiliser les informations de profil pour vérifier si l'utilisateur existe dans le backend de votre service. Si l'utilisateur n'existe pas, il peut créer un compte dans votre système à l'aide des informations de son profil Google.
Pour GSI, vous devez activer la création de compte par commande vocale, ce qui permet à l'utilisateur de terminer l'intégralité du flux par commande vocale. Pour en savoir plus sur les GSI, consultez le guide de concept Google Sign-In.
Association OAuth
Avec le type d'association OAuth, l'utilisateur se connecte via le flux OAuth 2.0 standard.
Le type d'association OAuth est compatible avec deux flux OAuth 2.0 standards dans l'industrie : les flux de code implicites et d'autorisation.
Google ne recommande pas le type d'association OAuth en lui-même, car il nécessite de transférer l'utilisateur d'un écran à un autre pour terminer le processus de connexion s'il se trouve sur un appareil non blindé. Vous pouvez envisager d'utiliser cette procédure si vous avez déjà mis en œuvre un serveur OAuth 2.0 et que vous ne pouvez pas étendre le point de terminaison d'échange de jetons afin d'ajouter la compatibilité avec les protocoles Google pour l'association automatique et la création de compte à partir d'un jeton d'ID. Pour en savoir plus, consultez le Guide sur le concept d'association OAuth.
Affiner le flux
Lorsque vous utilisez le type d'association OAuth dans votre action, vous devez spécifier la réponse à la question suivante dans la console Actions pour en définir le fonctionnement:
Voulez-vous utiliser le flux de code d'autorisation ou le flux implicite ?
Le type d'association OAuth est compatible avec deux flux OAuth 2.0 standards dans l'industrie : les flux de code implicites et d'autorisation. Le flux de code d'autorisation et le flux implicite diffèrent dans la mesure où le flux de code d'autorisation nécessite un deuxième point de terminaison, le point de terminaison d'échange de jetons. Ce point de terminaison utilise des jetons d'actualisation pour générer de nouveaux jetons d'accès de courte durée sans inviter l'utilisateur à se reconnecter.
À l'inverse, si vous utilisez le flux implicite, vous renvoyez à Google un jeton d'accès de longue durée qui n'a généralement pas besoin d'être généré de nouveau. Pour en savoir plus sur le code d'autorisation et les flux implicites, consultez le Guide des concepts d'association OAuth.
Google vous recommande d'utiliser le flux de code d'autorisation dans votre action, car il est plus sécurisé. Toutefois, utilisez plutôt le flux implicite si votre service ne peut pas stocker d'informations confidentielles (c'est-à-dire un code secret de client).
Par exemple, vous devez utiliser le flux implicite pour les clients publics tels que les applications monopages (SPA).
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/25 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/25 (UTC)."],[[["\u003cp\u003eThe optimal account linking type for your Google Action depends on user experience, whether you allow voice account creation, accept non-Google accounts, and if your service can handle confidential information.\u003c/p\u003e\n"],["\u003cp\u003eA decision tree helps you determine the best account linking type: OAuth-based Google Sign-in "Streamlined", Google Sign-in, or standard OAuth linking.\u003c/p\u003e\n"],["\u003cp\u003eStreamlined linking combines Google Sign-in benefits with support for non-Google accounts, offering flexibility and a smooth user experience.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Sign-in allows voice account creation and leverages users' Google profiles but may not be ideal if you require extensive control over the account creation process.\u003c/p\u003e\n"],["\u003cp\u003eStandard OAuth linking, while functional, might necessitate switching between voice and screen, potentially hindering user experience.\u003c/p\u003e\n"]]],["Account linking type selection depends on voice account creation, non-Google sign-in, and secure storage capabilities. To choose, consider if users have Google accounts and if existing OAuth can support Google protocol. Streamlined linking combines Google Sign-In (GSI) with OAuth, offering voice account creation unless full control or existing account sign-in is required. Authorization code flow is preferred for security unless a service can't store confidential information, in which case the implicit flow is necessary. GSI requires voice account creation. OAuth linking by itself isn't recommended.\n"],null,["# Choose your account linking type\n\nThe optimal account linking type for your Action is one that provides the\nsimplest experience for your users and fits the needs of your application or\nbusiness. Choosing your linking type is mostly dependent on the following\nfactors:\n\n- Whether you want to allow account creation via voice\n- Whether you want users to be able to sign in to your service with a non-Google account\n- Whether or not your service can store confidential information (i.e., a client secret)\n\nTo figure out your ideal account linking type, follow these steps:\n\n1. Consider the questions in the [Identify your preferred sign-in type](#identify_your_preferred_sign-in_type) section.\n2. Consult the decision tree to choose your linking type.\n3. Navigate to the section that corresponds to the initial type you chose to further refine how it works.\n\nIdentify your preferred sign-in type\n------------------------------------\n\nBefore you consult the decision tree, consider the following questions:\n\n- **Do you expect all your users to have a Google account?**\n - 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.\n - 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.\n- **If you have an OAuth implementation, can it be extended to support Google\n protocol?**\n - 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.\n\nFollow the decision tree below to identify the account linking type that's\noptimal for you and your users:\n\nOnce you select a linking type, continue to the corresponding section\nbelow to learn more about how it works and make further decisions about how\naccount linking works in your Action.\n\n### OAuth-based Google Sign-in \"Streamlined\" linking\n\nThe Streamlined linking type adds Google Sign-in (GSI) on top of OAuth-based\naccount linking, which provides the benefits of GSI (for example, voice-based\nlinking for Google users) while also enabling account linking for users who\nregistered to your service with a non-Google account. This linking type is\nespecially advantageous for end users because it provides a low-friction flow\nfor Google users with a fallback for non-Google users. For more information\nabout how Streamlined linking works, see the\n[OAuth-based Google Sign-in \"Streamlined\" linking concept guide](/assistant/identity/gsi-oauth-concept-guide).\n\n#### Refine OAuth-based Google Sign-in \"Streamlined\" linking type\n\nWhen you use the Streamlined linking type in your Action, you specify\nthe answers to the following questions in the Actions console to define how\nit works:\n\n1. **Do you want to enable voice account creation or only allow account\n creation on your website?**\n\n Generally, you should enable account creation via voice so that\n users on a non-screened device can create an account without having to\n transfer to another device. If you do not allow account creation via voice,\n Assistant opens the URL to the web site that you provided for user\n authentication and directs the user to a phone to continue the account\n linking flow.\n\n However, you should not allow account creation via voice if any of the\n following applies:\n 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.\n 2. *You want to ensure that users who already have an account with you\n 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.\n2. **Do you want to use the authorization code flow or implicit flow?**\n\n The authorization code flow and implicit flow differ in that the\n authorization code flow requires a second endpoint, the *token exchange*\n endpoint. This endpoint uses *refresh tokens* to generate new, short-lived\n access tokens without prompting the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth-based Google Sign-In \"Streamlined\" linking concept guide](/assistant/identity/gsi-oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs).\n\nAfter considering these decision points, consult the following decision tree:\n\n### Google Sign-in\n\nWith the Google Sign-in (GSI) linking type, your Action can request access to your user's Google\nprofile during a conversation and use the profile information to check if the\nuser exists in your service's backend. If the user doesn't exist, they can\ncreate a new account in your system using their Google profile information.\n\nFor GSI, you must enable account creation via voice, which lets the user\ncomplete the entire flow over voice. For more information about GSI, see the\n[Google Sign-In concept guide](/assistant/identity/gsi-concept-guide).\n\n### OAuth linking\n\nWith the OAuth linking type, the user signs in with the standard OAuth 2.0 flow.\nThe OAuth linking type supports two industry-standard OAuth 2.0 flows:\nthe *implicit* and *authorization* code flows.\n\nGoogle does not recommend the OAuth linking type by itself because it requires transferring\nthe user from voice to screen to complete the sign-in process if the user is on\na non-screened device. You can consider using this flow if you have an existing\nimplementation of an OAuth 2.0 server, and you cannot extend the token exchange\nendpoint to add support for Google's protocols for automatic linking and\naccount creation from an ID token. For more information, see the\n[OAuth linking concept guide](/assistant/identity/oauth-concept-guide).\n\n#### Refine the flow\n\nWhen you use the OAuth linking type in your Action, you must\nspecify the answer to the following question in the Actions console to define\nhow it works:\n\n1. **Do you want to use the authorization code flow or implicit flow?**\n\n The OAuth linking type supports two industry-standard OAuth 2.0 flows:\n the *implicit* and *authorization* code flows. The authorization code flow\n and implicit flow differ in that the authorization code flow requires a\n second endpoint, the *token exchange* endpoint. This endpoint uses\n *refresh tokens* to generate new, short-lived access tokens without prompting\n the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth linking concept guide](/assistant/identity/oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs)."]]
