Guide conceptuel sur les associations Google Sign-In basées sur OAuth

Le type d'association "Simplifié" de Google Sign-In basé sur OAuth ajoute Google Sign-In à l'association de compte basée sur OAuth. Si vous utilisez ce type d'association dans votre action, le flux commence par Google Sign-In, qui vous permet de vérifier si les informations du profil Google de l'utilisateur existent dans votre système. Si ce n'est pas le cas, un flux OAuth standard commence. En combinant ces deux types d'association, vos utilisateurs peuvent associer leur identité dans votre action à un compte Google ou autre. S'il le souhaite, il peut également créer un compte avec les informations de son profil Google.

L'association rationalisée est la solution d'association de compte recommandée si l'une des conditions suivantes s'applique:

  • Vous disposez d'une action couvrant plusieurs plates-formes (par exemple, si elle fonctionne avec une application Android).
  • Vous disposez d'un système d'authentification existant et vous souhaitez autoriser les utilisateurs à associer leur identité à des comptes autres que Google. Par exemple, si vous proposez un programme de fidélité et que vous souhaitez vous assurer que l'utilisateur ne perd pas les points accumulés dans son compte existant.

Pour vérifier que l'association rationalisée est la solution qui vous convient, consultez la page Choisir votre type d'association de compte.

Termes clés

Avant de découvrir le fonctionnement de la liaison rationalisée, familiarisez-vous avec les termes suivants:

  • Jeton d'ID Google:assertion signée de l'identité d'un utilisateur, contenant les informations de base de son profil Google (nom, adresse e-mail et photo de profil). Un jeton d'ID Google est un jeton Web JSON (JWT). Voici un exemple de jeton décodé:
{
  "sub": 1234567890,        // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The token's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Client ID assigned to your Actions project
  "iat": 233366400,         // Unix timestamp of the token's creation time
  "exp": 233370000,         // Unix timestamp of the token's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "jan@gmail.com", // If present, the user's email address
  "locale": "en_US"
}
  • user.verificationStatus:propriété définie par le système pour indiquer si la session en cours comporte un utilisateur validé.

  • user.accountLinkingStatus:propriété définie par le système pour indiquer si l'utilisateur de la session en cours est associé à une identité.

  • Scène système d'association de comptes:scène prédéfinie qui implémente le flux de confirmation pour l'association de comptes et peut être personnalisée pour répondre à des cas d'utilisation spécifiques.

  • Flux avec code d'autorisation:flux OAuth 2.0 que vous pouvez implémenter avec les liens simplifiés. Ce flux nécessite deux points de terminaison:

    • Point de terminaison de l'autorisation:point de terminaison qui présente l'UI de connexion aux utilisateurs qui ne sont pas déjà connectés. Elle enregistre le consentement à l'accès demandé sous la forme d'un code d'autorisation de courte durée.
    • Point de terminaison Token Exchange:ce point de terminaison est responsable de deux types d'échanges :
      1. Échange un code d'autorisation contre un jeton d'actualisation de longue durée et un jeton d'accès de courte durée. Cet échange se produit lorsque l'utilisateur passe par le flux d'association de compte.
      2. Échange un jeton d'actualisation de longue durée contre un jeton d'accès de courte durée. Cet échange se produit lorsque Google a besoin d'un nouveau jeton d'accès, car celui-ci a expiré.
  • Flux de code implicite:flux OAuth 2.0 que vous pouvez implémenter avec l'association simplifiée. Ce flux ne nécessite qu'un point de terminaison d'autorisation. Au cours de ce flux, Google ouvre votre point de terminaison d'autorisation dans le navigateur de l'utilisateur. Si la connexion aboutit, vous renvoyez un jeton d'accès de longue durée à Google. Ce jeton d'accès est désormais inclus dans chaque requête envoyée de l'Assistant à votre action.

  • Jeton d'accès:jeton qui autorise votre service à accéder à certaines données d'un utilisateur. Les jetons d'accès sont associés à chaque utilisateur individuel.

  • Jeton d'actualisation:jeton échangé contre un nouveau jeton d'accès lorsqu'un jeton d'accès de courte durée a expiré.

Conditions préalables

Pour utiliser le type d'association simplifiée, vous avez besoin des éléments suivants:

  • Un serveur OAuth 2.0
  • Un point de terminaison d'échange de jetons

    Le point de terminaison d'échange de jetons doit être étendu pour permettre l'association automatique et la création de comptes à partir d'un jeton d'ID avec les protocoles de Google (c'est-à-dire ajouter les paramètres intent=get et intent=create dans les requêtes adressées à ce point de terminaison).

Fonctionnement

Cette section décrit le processus général d'association rationalisée. La section suivante, Flux d'association simplifiées, décrit les différents flux qui peuvent se produire selon a) si vous activez ou désactivez la création de compte par commande vocale, et b) si vous utilisez le flux de code implicite ou d'autorisation.

Voici le flux de base:

  1. Votre action demande à l'utilisateur l'autorisation d'accéder à son profil Google.
  2. Une fois que l'utilisateur a donné son consentement, votre action reçoit un jeton d'ID Google contenant les informations de son profil Google.
  3. Vous devez valider et décoder le jeton pour lire le contenu du profil.
  4. Votre action utilise ce jeton pour vérifier si les informations du profil Google de l'utilisateur existent dans votre système.
    1. Si c'est le cas, cela signifie que l'utilisateur s'est déjà connecté à votre système avec son compte Google et que l'Assistant associe l'identité de l'utilisateur à son compte Google. L'utilisateur peut poursuivre la conversation avec l'Assistant en associant son compte.
    2. Si ce n'est pas le cas, passez à l'étape 5.
  5. L'utilisateur peut a) créer un compte avec les informations de son profil Google ou b) se connecter à votre système avec un autre compte. Les choix proposés à l'utilisateur diffèrent selon que vous activez ou désactivez la création de compte par commande vocale. Si l'utilisateur choisit de se connecter à votre système avec un autre compte, le flux OAuth standard commence.
  6. Une fois que l'utilisateur a créé un compte ou s'est connecté auprès d'un autre fournisseur, votre service renvoie un jeton d'accès à Google. (Si vous utilisez le flux de code d'autorisation, votre service renvoie également un jeton d'actualisation.)
  7. L'utilisateur peut désormais poursuivre la conversation avec l'Assistant lorsque son compte est associé.

Flux d'association simplifiés

Cette section passe en revue les différents flux pouvant être générés avec l'association rationalisée. Ces schémas passent en revue les flux qui se produisent avec le flux de code d'autorisation plutôt qu'avec le flux de code implicite et supposent que vous utilisez Actions Builder.

Chaque flux contient ces étapes courantes après que l'utilisateur a appelé votre action:

Dans le flux ci-dessus, vous passerez à la scène du système d'association de comptes et fournirez une justification personnalisée. Elle demande à l'utilisateur l'autorisation d'accéder aux informations de son profil Google. Une fois que l'utilisateur a donné son consentement, l'Assistant envoie une requête contenant les informations de profil pour user@gmail.com.

Les étapes qui suivent varient selon que vous configurez ou non l'association de compte à l'aide de commandes vocales et si les informations de l'utilisateur existent déjà dans votre système. Chacun de ces flux est décrit dans les sections suivantes.

Flow avec création de compte Voice activée

Cette section détaille les flux d'association de comptes qui peuvent se produire si vous activez la création de compte par commande vocale.

Flux 1: Les informations de l'utilisateur existent dans votre système

Dans ce cas, l'utilisateur représenté par user@gmail.com existe dans votre backend. Par conséquent, le point de terminaison d'échange de jetons renvoie un jeton pour l'utilisateur. L'identité de l'utilisateur dans votre action est désormais associée à son compte Google. La requête d'origine de l'utilisateur (Commander mon habitude) correspond à l'intent de l'utilisateur. order_drink. Votre webhook gère alors le traitement de l'intent correspondant et interroge votre base de données pour l'ordre habituel de user@gmail.com. L'utilisateur peut alors poursuivre sa conversation avec l'Assistant.

Flow 2: Les informations de l'utilisateur n'existent pas et l'utilisateur crée un compte

Comme vous avez activé la création de compte par commande vocale et que user@gmail.com n'existe pas dans votre backend, l'Assistant demande à l'utilisateur s'il souhaite effectuer l'une des opérations suivantes:

a) Créer un compte sur votre système à l'aide de ses informations de profil Google, par commande vocale

b) Connectez-vous à votre système avec un autre compte.

Dans ce cas, l'utilisateur choisit de créer un nouveau compte par commande vocale. Google appelle le point de terminaison d'échange de jetons de votre service avec une requête de création de compte. Cette requête contient le jeton d'ID Google, qui inclut les composants nécessaires à la création d'un compte. Vous pouvez ensuite utiliser les informations de ce jeton (nom et adresse e-mail de l'utilisateur) pour créer un compte pour l'utilisateur.

Une fois le compte créé, votre service renvoie un jeton d'accès et un jeton d'actualisation pour le compte nouvellement créé. L'identité de l'utilisateur dans votre action est désormais associée à son compte Google. La requête d'origine de l'utilisateur (Order my unknown) correspond à l'intent utilisateur order_drink. Votre webhook gère alors le traitement de l'intent correspondant et interroge votre base de données pour la commande habituelle de user@gmail.com, qui n'existe pas encore, car l'utilisateur est nouveau. Votre action peut ensuite demander à l'utilisateur ce qu'il souhaite commander.

Flow 3: Les informations de l'utilisateur n'existent pas et l'utilisateur se connecte avec un autre compte

Vous avez activé la création de compte par commande vocale. L'Assistant demande donc à l'utilisateur s'il souhaite effectuer l'une des opérations suivantes:

a) Créer un compte sur votre système à l'aide de ses informations de profil Google, par commande vocale

b) Connectez-vous à votre système avec un autre compte.

Dans ce cas, l'utilisateur choisit de se connecter avec un autre compte, ce qui lance le flux OAuth standard. Si le flux a commencé sur un appareil à commande vocale uniquement, Google transfère l'exécution sur un téléphone. Google ouvre ensuite votre point de terminaison d'autorisation dans le navigateur de l'utilisateur et, selon votre configuration, l'utilisateur peut choisir de se connecter à votre service avec un compte existant qui n'utilise pas Google Sign-In ou b) de créer un compte via un autre fournisseur. Pour en savoir plus sur le flux OAuth, consultez le Guide sur le concept d'association OAuth.

Après avoir vérifié les identifiants de l'utilisateur, votre service renvoie un jeton d'accès et un jeton d'actualisation à Google. L'identité de l'utilisateur dans votre action est désormais associée à un compte autre que Google. La requête d'origine de l'utilisateur (Order my preferred) correspond à l'intent utilisateur order_drink. Votre webhook gère alors le traitement de l'intent correspondant et interroge votre base de données pour l'ordre habituel de user@gmail.com, qui n'existe pas encore, car l'utilisateur est nouveau. Votre action peut ensuite demander à l'utilisateur ce qu'il souhaite commander ou lui demander de configurer sa commande habituelle.

Procédure avec création de compte Voice désactivée

Cette section détaille le flux d'association de comptes qui peut se produire si vous désactivez la création de compte par commande vocale.

Flux 4: Les informations de l'utilisateur n'existent pas

Vous n'avez pas activé la création de compte par commande vocale et l'utilisateur n'existe pas dans votre backend. Le flux OAuth standard commence donc. L'Assistant ouvre votre point de terminaison d'autorisation dans le navigateur de l'utilisateur (si le flux a commencé sur un appareil à commande vocale, Google transfère l'exécution vers un appareil doté d'un écran). L'utilisateur peut choisir de se connecter (a) auprès d'un autre fournisseur (s'il s'est inscrit à votre service avec un autre compte) ou de b) créer un compte auprès d'un autre fournisseur. Pour en savoir plus sur le flux OAuth, consultez le Guide sur le concept d'association OAuth.

Après avoir vérifié les identifiants de l'utilisateur, votre service renvoie un jeton d'accès et un jeton d'actualisation à Google. L'identité de l'utilisateur dans votre action est désormais associée à un compte autre que Google. La requête d'origine de l'utilisateur (Order my preferred) correspond à l'intent utilisateur order_drink. Votre webhook gère alors le traitement de l'intent correspondant et interroge votre base de données pour l'ordre habituel de user@gmail.com, qui n'existe pas encore, car l'utilisateur est nouveau. Votre action peut ensuite demander à l'utilisateur de configurer son ordre habituel.