Si vous ne connaissez pas encore les services ou autorisations Google Identity, 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 de l'utilisateur et à travailler plus facilement avec les 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 lancer le flux de code d'autorisation qui se termine sur votre plate-forme backend.
Champs d'application de l'authentification uniquement
Plusieurs champs d'application sont utilisés uniquement 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 la fonctionnalité Se connecter avec Google permettent à l'utilisateur de s'inscrire ou de se connecter en fonction de ses besoins. Dans la plupart des cas, il s'agit de la méthode la plus simple et la plus simple pour authentifier les utilisateurs.
Termes et concepts clés
Ces guides supposent que vous avez des connaissances de base sur les concepts OAuth 2.0 et les normes IETF telles que RFC6749. Les termes suivants sont utilisés dans tous les guides d'autorisation:
- Le jeton d'accès est un identifiant temporaire créé par Google pour chaque utilisateur. Il permet d'appeler les API Google et d'accéder aux données utilisateur de manière sécurisée.
- Le 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.
- Le jeton d'actualisation est un identifiant de longue durée par identifiant utilisateur émis par Google. Il est stocké de manière sécurisée sur votre plate-forme et peut être utilisé pour obtenir un nouveau jeton d'accès valide, même en cas d'absence de l'utilisateur.
- Le champ d'application limite les jetons à une quantité définie et limitée de données utilisateur. Pour en savoir plus, consultez les Champs d'application OAuth 2.0 pour les API Google.
- Le mode pop-up est un flux de 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 responsable de l'envoi du code d'autorisation à votre plate-forme. C'est vous qui déterminez comment cela fonctionne.
- Le mode redirection est un flux de code d'autorisation basé sur les redirections HTTP. Le user-agent est d'abord redirigé vers Google, puis le code Google est redirigé vers le point de terminaison du code d'autorisation de votre plate-forme.
Les durées de vie des jetons sont définies par Google, en tant qu'émetteur. La durée exacte peut varier en fonction de divers facteurs.
Flux OAuth 2.0
Nous abordons deux flux : le code implicite et le code d'autorisation. Les deux renvoient un jeton d'accès adapté à l'utilisation des API Google.
Le flux de code d'autorisation est recommandé, car il offre une sécurité renforcée aux utilisateurs. Ce flux renvoie également un jeton d'actualisation permettant d'obtenir des jetons d'accès sans que l'utilisateur soit présent, ce qui permet à votre plate-forme d'effectuer plus facilement des actions asynchrones, telles que l'envoi par SMS d'une réunion à venir planifié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 des services Google Identity suit la norme OAuth 2.0 pour:
- gérer le flux implicite pour permettre à votre application Web dans le navigateur d'obtenir rapidement et facilement un jeton d'accès auprès de Google pour appeler les API Google ;
- démarrer le flux du code d'autorisation à partir du navigateur de l'utilisateur ;
Procédure courante
Le flux de code implicite et le code d'autorisation commencent de la même manière:
- Votre application demande l'accès à un ou plusieurs champs d'application.
- Google affiche une boîte de dialogue de collecte du consentement de 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 tout champ d'application approuvé.
Lorsque vous utilisez le flux de code d'autorisation
- Google répond avec un code d'autorisation par utilisateur :
- En mode redirection, le code est renvoyé au point de terminaison du code d'autorisation de votre plate-forme.
- En mode pop-up, le code est renvoyé au gestionnaire de rappel de votre application dans le 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 se traduit par le renvoi d'un jeton d'actualisation par utilisateur et d'un jeton d'accès à votre plate-forme.
Autorisation de l'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 collecte du consentement à l'étape 2 ci-dessus et enregistre le résultat sur myaccount.google.com/permissions.
Le nom, le logo, les règles de confidentialité, les conditions d'utilisation et les champs d'application demandés sont affichés à l'utilisateur, avec la possibilité d'approuver ou d'annuler la requête.
La figure 1 montre la boîte de dialogue de collecte du consentement pour un seul champ d'application. Lorsqu'un 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 collecte du consentement de l'utilisateur avec un seul champ d'application.
La figure 2 montre la boîte de dialogue de collecte 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 collecte du consentement de l'utilisateur avec plusieurs champs d'application.
Comptes utilisateur
Un compte Google est nécessaire pour enregistrer le consentement et émettre un jeton d'accès. Auparavant, les utilisateurs individuels doivent s'authentifier auprès de Google en se connectant à un compte Google.
Bien que cela ne soit pas obligatoire, il est recommandé d'utiliser la fonctionnalité Se connecter avec Google pour l'inscription et la connexion à votre application Web ou à votre plate-forme de backend. Cela permet de faciliter la tâche des utilisateurs en réduisant 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 à l'utilisateur de devoir se connecter à un compte Google ultérieurement 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 obtenir le 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 d'effectuer une étape. L'identifiant du jeton d'ID renvoyé par la fonctionnalité Se connecter avec Google contient l'adresse e-mail de l'utilisateur.
Les applications Web exécutées uniquement dans le navigateur peuvent s'appuyer uniquement sur Google pour l'authentification des utilisateurs, choisissant de ne pas mettre en œuvre un 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 de gérer le stockage sécurisé.
Un système de compte utilisateur est également requis pour le flux de 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 mise en œuvre, l'utilisation et la gestion d'un système de compte utilisateur sont propres à votre plate-forme et ne sont pas abordées plus en détail.
Afficher et révoquer le consentement
Les utilisateurs peuvent consulter ou révoquer leur consentement à tout moment dans les paramètres de leur compte Google.
Votre application Web ou votre plate-forme peut éventuellement appeler google.accounts.oauth2.revoke pour révoquer les jetons et supprimer le consentement de l'utilisateur, ce qui 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 la section OAuth 2.0 pour les applications Web côté client.
De même, pour le flux de code d'autorisation, vous pouvez choisir d'implémenter vos propres méthodes et de 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 réduire les risques de sécurité tels que ceux décrits par les bonnes pratiques de sécurité OAuth 2.0.