Si vous ne connaissez pas les services ou l'autorisation Google Identity, commencez par lire la présentation.
Google propose une bibliothèque JavaScript comprenant des fonctionnalités d'autorisation pour vous aider à gérer les champs d'application, obtenir l'autorisation des utilisateurs et utiliser plus facilement 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 de l'utilisateur: email, profile et openid. Si votre application n'utilise que ces champs d'application, déterminez si un jeton d'ID JWT et Sign In With Google pour l'inscription et la connexion répondent aux besoins de l'utilisateur. Dans la plupart des cas, il s'agit de la méthode la plus simple et la plus simple disponible pour l'authentification des utilisateurs.
Concepts clés
Ces guides supposent que vous maîtrisez les principes de base d'OAuth 2.0 et des 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, émis par Google, qui permet d'appeler les API Google de manière sécurisée et d'accéder aux données utilisateur.
- 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 à partir d'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 à long terme par 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 si l'utilisateur n'est pas présent.
- Scope limite les jetons à une quantité limitée et définie 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'authentification à votre plate-forme. Vous êtes responsable de cette opération.
- Le mode Redirection est un flux de code d'autorisation basé sur les redirections HTTP. Le user-agent est d'abord redirigé vers Google, la deuxième redirection de Google vers votre point de terminaison de code d'autorisation de la plate-forme comprend le code.
La durée de vie des jetons est définie par Google en tant qu'émetteur. Pour diverses raisons, la durée exacte peut varier.
Parcours OAuth 2.0
Deux flux sont traités : le flux implicite et le code d'autorisation. Les deux renvoient un jeton d'accès adapté à l'utilisation des API Google.
Cette procédure est recommandée, car elle offre une sécurité utilisateur renforcée. Ce flux renvoie également un jeton d'actualisation pouvant être utilisé pour obtenir des jetons d'accès sans la présence de l'utilisateur, ce qui permet à votre plate-forme d'effectuer plus facilement des actions asynchrones, telles que l'envoi d'un rappel par SMS d'une réunion planifiée à la dernière minute. Choisissez un modèle d'autorisation pour découvrir plus en détail les différences entre ces deux flux.
La bibliothèque JavaScript des services Google Identity respecte la norme OAuth 2.0 en vue d'effectuer les opérations suivantes:
- 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, nécessaire pour appeler les API Google.
- Démarrez le flux de code d'autorisation à partir du navigateur de l'utilisateur.
Étapes courantes
Le flux de code implicite et le code d'autorisation commencent de la même manière:
- Votre appli demande l'accès à un ou plusieurs champs d'application.
- Google affiche une boîte de dialogue de collecte du consentement et, si nécessaire, connecte l'utilisateur à son compte Google, si nécessaire.
- L'utilisateur approuve individuellement chaque niveau d'accès demandé.
Chaque flux se termine par différentes étapes.
Lors de l'utilisation du parcours 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é.
Utilisation du flux de code d'authentification
- Google répond par un code d'autorisation par utilisateur :
- En mode redirection, le code est renvoyé au point de terminaison du code d'autorisation de la plate-forme.
- En mode pop-up, le code est renvoyé au gestionnaire de rappel de votre application dans le navigateur, sans que les utilisateurs n'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 finalise l'échange de serveur à serveur avec Google, ce qui entraîne l'envoi 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 la page myaccount.google.com/permissions.
Le nom, le logo, les règles de confidentialité, les conditions d'utilisation et les niveaux d'accès demandés sont affichés, et l'utilisateur a la possibilité d'approuver ou d'annuler votre demande.
La figure 1 illustre la boîte de dialogue de collecte du consentement pour une seule portée. Lorsqu'une portée est demandée, aucune case n'est nécessaire pour approuver ou refuser une habilitation.
Figure 1:Boîte de dialogue de collecte du consentement de l'utilisateur avec une seule portée.
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, vous devez les cocher pour autoriser ou 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'être authentifiés avec 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 backend. Cela permet de limiter les problèmes en limitant le nombre d'étapes requises et, si vous le souhaitez, d'associer facilement des jetons d'accès à des comptes individuels sur votre plate-forme.
Par exemple, l'utilisation de la fonctionnalité Se connecter avec Google établit une session de compte Google active, évitant ainsi de devoir ultérieurement inviter l'utilisateur à se connecter à un compte Google lors d'une demande d'autorisation. Si vous choisissez d'authentifier les utilisateurs dans votre application par d'autres moyens (nom d'utilisateur et mot de passe, par exemple) ou d'autres fournisseurs d'identité, ils devront tout d'abord se connecter à un compte Google pour obtenir le consentement.
L'ajout d'un indice 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 d'enregistrer une étape. L'identifiant du jeton d'ID affiché 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 se fier uniquement à Google pour l'authentification des utilisateurs, choisir de ne pas mettre en œuvre un système de gestion de compte 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 également requis par 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, la gestion et la gestion d'un système de compte utilisateur sont propres à votre plate-forme. Il n'est pas abordé plus en détail.
Afficher et révoquer votre consentement
Les utilisateurs peuvent consulter ou révoquer leur autorisation à 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 des jetons et retirer le consentement de l'utilisateur, 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 parcours 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 suivre la procédure décrite dans Utilisation d'OAuth 2.0 pour les applications de serveur Web.
Dans les deux cas, nous vous recommandons vivement d'utiliser la bibliothèque de services Google Identity pour réduire le temps et les efforts de développement et minimiser les risques de sécurité, tels que ceux décrits dans les bonnes pratiques sur la sécurité du protocole OAuth 2.0.