Si vous ne connaissez pas les services ou l'autorisation Google Identity Services, 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 à utiliser plus facilement les flux OAuth 2.0 standards. Votre application Web, qui s'exécute 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 de code d'autorisation qui se termine sur votre plate-forme backend.
Champs d'application de l'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 la fonctionnalité 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 et la plus simple pour authentifier les utilisateurs.
Termes et concepts clés
Ces guides supposent que vous avez une compréhension de base des concepts d'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 de courte durée pour chaque utilisateur, émis par Google et utilisé pour appeler les API Google et 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.
- Un jeton d'actualisation est un identifiant de longue durée pour chaque utilisateur et é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 l'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 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. Ce choix vous appartient.
- Le mode redirection est un flux de code d'autorisation basé sur des redirections HTTP. Le 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.
La durée de vie des jetons est définie par Google, en tant qu'émetteur. En raison de divers facteurs, la durée exacte peut varier.
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é à une utilisation avec les API Google.
Nous vous recommandons d'utiliser le flux avec code d'autorisation, car il offre une sécurité renforcée pour les utilisateurs. Ce flux renvoie également un jeton d'actualisation qui peut ê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 à venir planifiée à la dernière minute. L'article 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 respecte la norme OAuth 2.0 pour:
- gérer le flux implicite pour permettre à l'application Web intégrée au navigateur d'obtenir rapidement et facilement auprès de Google un jeton d'accès nécessaire pour appeler les API Google.
- Démarrez le flux de code d'autorisation depuis le navigateur de l'utilisateur.
Étapes courantes
Le flux implicite et le flux de 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 collecte du consentement et, si nécessaire, commence par signer l'utilisateur dans son compte Google.
- L'utilisateur approuve individuellement chaque champ d'application demandé.
Chaque flux se termine ensuite par différentes étapes.
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 de code d'autorisation
- 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 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 à 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 le renvoi d'un jeton d'actualisation et d'un jeton d'accès par utilisateur à 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 présentés à l'utilisateur, avec la possibilité d'approuver ou d'annuler la demande.
La figure 1 montre la boîte de dialogue de collecte du consentement pour un seul champ d'application. Lorsqu'un seul champ d'application est demandé, aucune case à cocher n'est nécessaire pour l'approuver ou le refuser.
Figure 1:Boîte de dialogue de recueil du consentement des utilisateurs 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 recueil 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. 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 la fonctionnalité Se connecter avec Google pour l'inscription et la connexion à votre application Web ou à votre plate-forme backend. Cela permet de réduire les frictions pour les utilisateurs en limitant le nombre d'étapes requises et vous permet éventuellement 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 active de compte Google, ce qui évite de devoir demander ultérieurement à l'utilisateur de se connecter à un compte Google lorsqu'il effectue une demande d'autorisation. Si vous choisissez d'authentifier les utilisateurs auprès de votre application par d'autres moyens, tels que leur nom d'utilisateur et leur mot de passe, ou par d'autres fournisseurs d'identité, ils devront d'abord se connecter à un compte Google pour obtenir leur autorisation.
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 du sélecteur de compte, ce qui permet aux utilisateurs d'éviter l'affichage d'une étape. Les identifiants de jeton d'ID renvoyés par la fonctionnalité Se connecter avec Google contiennent 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. Elles choisissent 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 ni à un espace de stockage sécurisé de gestion.
Un système de comptes 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 de 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 une autorisation
Les utilisateurs peuvent consulter ou révoquer leur consentement à tout moment dans les paramètres de leur compte Google.
Si vous le souhaitez, votre application Web ou votre plate-forme peut appeler google.accounts.oauth2.revoke pour révoquer des jetons et retirer 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 la section 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 afin de réduire le temps et les efforts de développement, et de minimiser les risques de sécurité, tels que ceux décrits dans les bonnes pratiques actuelles concernant la sécurité OAuth 2.0.