oauth 2.0 Code d'autorisation Google Home et authentification avec un compte Google



oauth-2.0 actions-on-google (1)

J'essaie actuellement d'authentifier un compte Google auprès d'une action Google Home et de récupérer le code d'autorisation à partir des informations d'identification. Je ne veux pas le jeton d'accès, mais le code d'autorisation .

J'ai consulté ce message et découvert que Google a mis à jour sa stratégie et n'autorise plus l'utilisation de ses propres points de terminaison OAuth pour le flux de codes d'autorisation associé au compte:

Lorsque vous implémentez la liaison de compte avec OAuth, vous devez posséder votre point de terminaison OAuth.

Cela étant dit,

  1. Quelle est la bonne façon d'authentifier un utilisateur Google existant avec mon action et les étendues nécessaires? (J'ai besoin d'accéder au calendrier)
  2. Est-il possible de faire cette authentification sans avoir à créer mes propres points de terminaison OAuth2.0?
  3. Et à partir de ce flux, est-il possible d'extraire le code d'autorisation ?

Le moyen actuel d'authentifier un utilisateur via son compte Google consiste à utiliser Google Sign-In for Assistant . Une fois qu’ils se connectent à votre action, vous obtenez un jeton d’identification que vous pouvez décoder pour obtenir leur identifiant Google, que vous pouvez utiliser pour rechercher leur compte dans votre magasin de données afin d’obtenir leurs jetons d’accès / actualisation.

Étant donné que vous avez besoin d'étendues supplémentaires, si l'utilisateur se connecte à l'Assistant et ne les a pas déjà attachées à son compte, vous les redirigerez vers une page de connexion basée sur le Web où ils pourront se connecter à l'aide de la connexion Google. portée dont vous avez besoin. Dans ce cas, lorsqu'ils se connecteront et autoriseront l'accès via le Web, vous obtiendrez le code d'autorisation que vous devrez échanger contre le jeton d'authentification et le jeton d'actualisation et de les stocker.

Vous n'avez pas besoin de créer vos propres points de terminaison OAuth pour cela, mais vous devrez effectuer un peu de travail supplémentaire pour vous assurer qu'ils seront redirigés vers votre site Web afin de procéder à l'autorisation, si nécessaire.

Vous n'obtiendrez le code d'autorisation qu'une fois lorsqu'ils se connecteront et vous autoriseront. Vous devrez échanger ceci contre les authentifications et les jetons d'actualisation, puis stocker ces jetons.

Mise à jour pour expliquer les choses un peu mieux.

En regardant l’architecture, nous voyons qu’elle a quelques composants. Nous entrerons dans les détails de chacun d’eux au fur et à mesure de la progression du processus:

  • Vous avez un magasin de données de quelque sorte, où vous allez stocker le jeton d'authentification et le jeton de rafraîchissement pour l'utilisateur. Je suppose que vous utilisez l'ID utilisateur de Google comme index pour ce magasin de données.

    • Par "ID d'utilisateur Google" dans ce cas, j'entends l'identifiant numérique unique que Google attribue à chaque compte. Ceci est souvent représenté par une chaîne, même si elle ne contient que des chiffres numériques, car il est généralement beaucoup plus long que la plupart des types numériques. Dans le jeton d'identification, il s'agit de la revendication "sub".

    • En théorie, vous pouvez utiliser d'autres identifiants disponibles à partir des revendications du jeton d'identifiant, tels que leur adresse électronique. Malheureusement, tous ces champs ne sont pas assurés d'être disponibles - seul le "sous" est garanti.

  • Vous avez un serveur Web qui aura quelques URL importantes pour nos besoins:

    • Le Webhook pour votre accomplissement d'action.
    • Une page de connexion / auth.
    • Un point d'extrémité où le javascript de la page de connexion vous enverra le code d'autorisation.
  • L’assistant Google, qui s'exécute peut-être sur Google Home ou sur un appareil mobile. Nous supposons également que l'utilisateur sera capable d'accéder à un navigateur pour vérifier ce qu'il autorise.

  • Les services Google que vous utiliserez, y compris le service Google OAuth

Commençons par le cas où l'utilisateur s'est déjà connecté et nous a autorisé à accéder au service en son nom. Nous avons leurs jetons d’authentification et de rafraîchissement dans notre magasin de données, indexés par rapport à leur identifiant Google. C'est un cas simple, mais cela nous aide à comprendre le cas plus complexe de la manière dont toutes ces données sont stockées.

Le flux de données ressemble à ceci:

  1. L’assistant envoie à l’action Webhook une intention et les paramètres possibles. S'il s'agit du premier message, c'est une intention bienvenue, mais cela n'a pas d'importance. Il comprend un jeton d'identité que nous devrons décoder et vérifier. En tant que partie des données que nous obtenons lorsque nous les décodons, elles incluent l'identifiant de l'utilisateur.
  2. Utilisation de l'ID utilisateur…
  3. ... nous obtenons le jeton d'authentification et le jeton d'actualisation à partir du magasin de données.
  4. Avec le jeton d'authentification et le jeton d'actualisation, nous pouvons mener une action contre les services de Google, agissant pour le compte de l'utilisateur.
  5. Nous allons obtenir des résultats du service…
  6. ... que nous voulons généralement renvoyer à l'utilisateur sous une forme ou une autre.

Facile, non? Mais que se passe-t-il si l'utilisateur n'a jamais utilisé l'assistant pour parler à notre action auparavant? Et ne nous a jamais autorisés à accéder à leurs services Google, nous n'avons donc pas leurs jetons? Ce flux ressemble plus à ceci:

  1. L'assistant envoie à l'action Webhook une intention et les paramètres possibles. Ce sera le premier message, alors notre intention de bienvenue est déclenchée. Il n'y a pas de jeton d'identité.
  2. Le Webhook constate qu'il n'y a pas de jeton d'identité et renvoie donc un message demandant la fonction d'assistance «Sign In». Étant donné que votre projet est configuré pour utiliser Google Sign-In, l'Assistant demandera à l'utilisateur s'il peut vous donner les informations de son profil.
  3. S'ils répondent par l'affirmative, vous obtiendrez une autre réponse indiquant qu'ils se sont connectés et comprenant le jeton d'identité, que nous décodons, vérifions et obtenons leur ID utilisateur. (S'ils disent non, nous obtiendrons une réponse disant que cela a échoué. Votre façon de gérer cela est une autre histoire. Je vais supposer qu'ils disent oui.)
  4. Utilisation de l'ID utilisateur…
  5. ... nous essayons d'obtenir le jeton d'authentification et le jeton d'actualisation à partir du magasin de données. Mais ils ne nous ont pas encore autorisés. Nous les avons authentifiés , mais n'avons pas d' autorisation ...
  6. ... nous envoyons donc un message indiquant qu'ils doivent consulter notre site Web pour nous autoriser à accéder à leurs services Google. Nous pouvons leur demander de passer sur un appareil mobile pour faire cette partie et même inclure un lien vers la page de connexion.
  7. Ils suivront le lien sur un appareil doté d'un écran.
  8. Nous vous renverrons la page de connexion, qui comprend un lien vers la connexion avec Google. Nous avons configuré ce bouton pour demander également les étendues supplémentaires dont nous avons besoin pour accéder à leurs services, ainsi que l'autorisation d'accéder aux services en leur nom lorsqu'elles sont «hors ligne».
  9. Ils passeront par la fenêtre de connexion à Google, l'écran OAuth Scopes, et, espérons-le, accorderont toutes les autorisations souhaitées. (Encore une fois, j'ignore ce qui se passe s'ils ne le font pas.) J'omets à quoi ressemble cette danse puisqu'elle ne nous concerne pas. En supposant que tout se passe bien, Google leur attribue un code d'autorisation que le javascript de la page de connexion nous envoie.
  10. Nous appelons les serveurs OAuth de Google pour vérifier le code d'authentification et l'utiliser pour obtenir le jeton d'authentification et le jeton d'actualisation…
  11. … Que nous stockons ensuite dans le magasin de données…
  12. … Et ensuite renvoyer quelque chose pour que la page Javascript puisse dire à l'utilisateur qu'il peut utiliser notre action normalement à partir de maintenant.

Ce qu’ils peuvent maintenant faire, et il se comporte comme auparavant. Un scénario simple.

Cela semble complexe, mais il s'avère que nous pouvons supprimer certaines étapes dans certains cas. Si le projet Google Cloud est le même projet que vous utilisez à la fois pour votre action et pour la connexion Web basée sur Google, alors une fois qu'ils ont autorisé le projet sur le Web, tous les appels à votre réalisation incluront le jeton d'identité. Cela nous permet de supprimer les étapes 2 à 6 ci-dessus, afin que les choses se présentent plutôt comme suit:

  1. L'assistant envoie à l'action Webhook une intention et les paramètres possibles. Ce sera le premier message, alors notre intention de bienvenue est déclenchée. Il n'y a pas de jeton d'identité.
  2. Webhook constate qu'il n'y a pas de jeton d'identité. Nous vous renvoyons donc un message indiquant qu'ils doivent consulter notre site Web pour nous autoriser à accéder à leurs services Google. Nous pouvons leur demander de passer sur un appareil mobile pour faire cette partie et même inclure un lien vers la page de connexion. (Il s’agit des étapes 2 et 6 condensées d’en haut.)
  3. Ils suivront le lien sur un appareil doté d'un écran.
  4. Nous vous renverrons la page de connexion, qui comprend un lien vers la connexion avec Google. Nous avons configuré ce bouton pour demander également les étendues supplémentaires dont nous avons besoin pour accéder à leurs services, ainsi que l'autorisation d'accéder aux services en leur nom lorsqu'elles sont «hors ligne».
  5. Ils passeront par la fenêtre de connexion à Google, l'écran OAuth Scopes, et, espérons-le, accorderont toutes les autorisations souhaitées. (Encore une fois, j'ignore ce qui se passe s'ils ne le font pas.) J'omets à quoi ressemble cette danse puisqu'elle ne nous concerne pas. En supposant que tout se passe bien, Google leur attribue un code d'autorisation que le javascript de la page de connexion nous envoie.
  6. Nous appelons les serveurs OAuth de Google pour vérifier le code d'authentification et l'utiliser pour obtenir le jeton d'authentification et le jeton d'actualisation…
  7. … Que nous stockons ensuite dans le magasin de données…
  8. … Et ensuite renvoyer quelque chose pour que la page Javascript puisse dire à l'utilisateur qu'il peut utiliser notre action normalement à partir de maintenant.

Il convient également de noter que s’ils visitent le site Web avant même d’essayer la version Assistant (c’est-à-dire en raison d’un résultat de recherche ou quelle que soit leur origine, ils démarrent à l’étape 8 du deuxième diagramme ou 4 du troisième diagramme) et s’identifient, puis nous nous connectons. recevront leur jeton d’identité la première fois qu’ils nous rendent visite par l’assistant, et cela fonctionnera comme un simple scénario.