Si vous ne connaissez pas Google Identity Services ni l'autorisation, commencez par lire la présentation.
Google propose une bibliothèque JavaScript qui inclut des fonctionnalités d'autorisation pour vous aider à gérer les champs d'application, à obtenir le consentement utilisateur et à simplifier l'utilisation des flux OAuth 2.0 standards. Votre application Web, exécutée dans le navigateur de l'utilisateur, utilise cette bibliothèque pour gérer le flux implicite OAuth 2.0 ou pour démarrer le flux avec code d'autorisation qui se termine sur votre plate-forme backend.
Champs d'application d'authentification uniquement
Plusieurs champs d'application ne sont utilisés que pour l'authentification des utilisateurs : email, profile et openid. Si votre application n'utilise que ces champs d'application, déterminez si un jeton d'ID JWT et
Se connecter avec Google pour l'inscription et la connexion des utilisateurs répondent à vos besoins. Dans la plupart des cas, il s'agit de la méthode la plus simple disponible pour l'authentification des utilisateurs.
Termes et concepts clés
Ces guides partent du principe que vous disposez d'une compréhension de base des concepts OAuth 2.0 et des normes IETF telles que RFC6749. Les termes suivants sont utilisés dans les guides d'autorisation :
- Un jeton d'accès est un identifiant éphémère par utilisateur émis par Google qui est utilisé pour appeler de manière sécurisée les API Google et accéder aux données utilisateur.
- Un code d'autorisation est un code temporaire émis par Google pour identifier de manière sécurisée les utilisateurs individuels qui se connectent à leur compte Google depuis un navigateur. Votre plate-forme backend échange ce code contre des jetons d'accès et d'actualisation.
- Un jeton d'actualisation est un identifiant de longue durée par utilisateur émis par Google qui est stocké de manière sécurisée sur votre plate-forme et qui peut être utilisé pour obtenir un nouveau jeton d'accès valide, même lorsque l'utilisateur n'est pas présent.
- Un champ d'application limite les jetons à une quantité définie et limitée de données utilisateur. Pour en savoir plus, consultez la section Champs d'application OAuth 2.0 pour les API Google.
- Le mode pop-up est un flux avec code d'autorisation basé sur un rappel JavaScript exécuté dans le navigateur de l'utilisateur. Google appelle votre gestionnaire de rappel, qui est ensuite chargé d'envoyer le code d'autorisation à votre plate-forme. La méthode utilisée dépend de vous.
- Le mode de redirection est un flux avec code d'autorisation basé sur des redirections HTTP. L'user-agent est d'abord redirigé vers Google, puis une deuxième redirection de Google vers le point de terminaison du code d'autorisation de votre plate-forme inclut le code.
Les durées de vie des jetons sont définies par Google, en tant qu'émetteur. La durée exacte peut varier en raison de divers facteurs.
Flux OAuth 2.0
Deux flux sont abordés : le flux implicite et le flux avec code d'autorisation. Les deux renvoient un jeton d'accès adapté à une utilisation avec les API Google.
Le flux avec code d'autorisation est recommandé, car il améliore la sécurité des utilisateurs. Ce flux renvoie également un jeton d'actualisation qui peut être utilisé pour obtenir des jetons d'accès sans que l'utilisateur soit présent, ce qui permet à votre plate-forme d'effectuer des actions asynchrones, comme envoyer un SMS de rappel d'une réunion à venir qui a été programmée à la dernière minute. La section Choisir un modèle d'autorisation explique plus en détail les différences entre les deux flux.
La bibliothèque JavaScript Google Identity Services suit la norme OAuth 2.0 pour :
- gérer le flux implicite afin de permettre à votre application Web dans le navigateur d'obtenir rapidement un jeton d'accès de Google, nécessaire pour appeler les Google APIs.
- démarrer le flux avec code d'autorisation à partir du navigateur de l'utilisateur.
Étapes courantes
Les flux implicite et avec code d'autorisation commencent de la même manière :
- Votre application demande à accéder à un ou plusieurs champs d'application.
- Google affiche une boîte de dialogue de recueil du consentement à l'utilisateur et, si nécessaire, le connecte d'abord à son compte Google.
- L'utilisateur approuve individuellement chaque champ d'application demandé.
Chaque flux se termine ensuite par des étapes différentes.
Lorsque vous utilisez le flux implicite
- Google utilise un gestionnaire de rappel pour informer votre application du résultat du consentement et renvoyer un jeton d'accès pour tous les champs d'application approuvés.
Lorsque vous utilisez le flux avec code d'autorisation
- Google répond avec un code d'autorisation par utilisateur :
- En mode de redirection, le code est renvoyé au point de terminaison du code d'autorisation de votre plate-forme.
- En mode de boîte de dialogue, le code est renvoyé au gestionnaire de rappel de l'application dans votre navigateur, sans que les utilisateurs aient besoin de quitter votre site Web.
- À partir de l'étape 4 : Gérer la réponse du serveur OAuth 2.0, votre plate-forme backend effectue un échange de serveur à serveur avec Google, ce qui entraîne finalement le renvoi d'un jeton d'actualisation et d'un jeton d'accès par utilisateur à votre plate-forme.
Consentement utilisateur
Avant d'obtenir un jeton d'accès, les utilisateurs individuels doivent autoriser votre application à accéder aux champs d'application demandés. Pour ce faire, Google affiche une boîte de dialogue de recueil du consentement à l'étape 2 et enregistre le résultat dans myaccount.google.com/permissions.
Le nom de votre application, son logo, ses règles de confidentialité, ses conditions d'utilisation et les champs d'application demandés sont affichés à l'utilisateur, ainsi que l'option permettant d'approuver ou d'annuler la requête.
La figure 1 montre la boîte de dialogue de recueil du consentement pour un seul champ d'application. Lorsqu'un seul champ d'application est demandé, aucune case à cocher n'est nécessaire pour approuver ou refuser un champ d'application.
Figure 1 : Boîte de dialogue de recueil du consentement de l'utilisateur avec un seul champ d'application
La figure 2 montre la boîte de dialogue de recueil du consentement pour plusieurs champs d'application. Lorsque plusieurs champs d'application sont demandés, des cases à cocher individuelles sont nécessaires pour permettre à l'utilisateur d'approuver ou de refuser chaque champ d'application.
Figure 2 : Boîte de dialogue de recueil du consentement utilisateur avec plusieurs champs d'application
Comptes utilisateur
Un compte Google est requis pour enregistrer le consentement et émettre un jeton d'accès. Avant cela, les utilisateurs individuels doivent s'être authentifiés auprès de Google en se connectant à un compte Google.
Bien que cela ne soit pas obligatoire, il est recommandé d'utiliser Se connecter avec Google pour l'inscription et la connexion à votre application Web ou à votre plate-forme backend. Cela réduit les frictions des utilisateurs en minimisant le nombre d'étapes requises et vous permet éventuellement d'associer des jetons d'accès à des comptes individuels sur votre plate-forme.
Par exemple, l'utilisation de Se connecter avec Google établit une session de compte Google active, ce qui évite d'avoir à inviter l'utilisateur à se connecter à un compte Google lors d'une demande d'autorisation. Si vous choisissez d'authentifier les utilisateurs auprès de votre application par d'autres moyens, tels que le nom d'utilisateur et le mot de passe, ou d'autres fournisseurs d'identité, ils devront toujours se connecter à un compte Google pour donner leur consentement.
L'ajout d'un indice de connexion lors de l'initialisation de l'autorisation (généralement l' adresse e-mail du compte Google de l'utilisateur) permet à Google d'ignorer l'affichage d'un sélecteur de compte, ce qui permet aux utilisateurs de gagner du temps. L'identifiant de jeton d'ID renvoyé par Se connecter avec Google contient l'adresse e-mail de l'utilisateur.
Les applications Web qui ne s'exécutent que dans le navigateur peuvent s'appuyer uniquement sur Google pour l'authentification des utilisateurs, en choisissant de ne pas implémenter de système de gestion des comptes utilisateur. Dans ce scénario, appelé flux implicite, il n'est pas nécessaire d'associer un jeton d'actualisation à un compte utilisateur et à un stockage sécurisé de gestion.
Un système de compte utilisateur est requis par le flux avec code d'autorisation. Les jetons d'actualisation par utilisateur doivent être associés à un compte individuel sur votre plate-forme backend et stockés pour une utilisation ultérieure. La manière d'implémenter, d'utiliser et de gérer un système de compte utilisateur est propre à votre plate-forme et n'est pas abordée plus en détail.
Afficher et révoquer le consentement
Les utilisateurs peuvent afficher ou révoquer leur consentement à tout moment depuis les paramètres de leur compte Google.
Vous pouvez également appeler
google.accounts.oauth2.revoke dans votre application Web ou plate-forme pour révoquer les jetons et supprimer le consentement utilisateur.
Cela est utile lorsqu'un utilisateur supprime son compte de votre plate-forme.
Autres options d'autorisation
Les navigateurs peuvent également obtenir des jetons d'accès à l'aide du flux implicite en appelant directement les points de terminaison OAuth 2.0 de Google, comme décrit dans OAuth 2.0 pour les applications Web côté client.
De même, pour le flux avec code d'autorisation, vous pouvez choisir d'implémenter vos propres méthodes et suivre les étapes décrites dans Utiliser OAuth 2.0 pour les applications de serveur Web.
Dans les deux cas, nous vous recommandons vivement d'utiliser la bibliothèque Google Identity Services pour réduire le temps et les efforts de développement, et pour minimiser les risques de sécurité tels que ceux décrits dans les bonnes pratiques actuelles de sécurité OAuth 2.0.