Ce guide vous aide à choisir entre l'utilisation de la bibliothèque Google Identity Services pour l'autorisation des utilisateurs et l'implémentation de votre propre bibliothèque JavaScript. Il vous aide à choisir le flux d'autorisation OAuth 2.0 le mieux adapté à votre application Web.
Avant de lire ce guide, nous partons du principe que vous connaissez les termes et les concepts décrits dans les guides Présentation et Fonctionnement de l'autorisation des utilisateurs.
La bibliothèque GIS s'exécute dans ces navigateurs compatibles sur l'appareil de l'utilisateur. Elle n'est pas destinée à être utilisée avec des frameworks JavaScript côté serveur tels que Node.js. Utilisez plutôt la bibliothèque cliente Node.js de Google.
Ce guide ne couvre que les sujets liés à l'autorisation et au partage de données. Il n'examine pas l'authentification des utilisateurs. Consultez plutôt Se connecter avec Google et le guide Migrer depuis Google Sign-In pour l'inscription et la connexion des utilisateurs.
Déterminer si la bibliothèque GIS vous convient
Vous devez choisir si l'utilisation de la bibliothèque de Google ou la création de la vôtre répond le mieux à vos besoins. Voici une présentation des fonctionnalités :
- La bibliothèque JavaScript Identity Services de Google implémente les éléments suivants :
- Des flux de consentement basés sur des boîtes de dialogue pour minimiser les redirections, permettant aux utilisateurs de rester sur votre site tout au long du processus d'autorisation.
- Fonctionnalités de sécurité telles que la protection contre la falsification des requêtes intersites (CRSF).
- Méthodes d'assistance permettant de demander des niveaux d'accès individuels et de confirmer le consentement utilisateur.
- Gestion des erreurs conviviale et liens vers la documentation à utiliser par les ingénieurs lors du développement, puis par les visiteurs de votre site.
- Lorsque vous implémentez sans la bibliothèque Identity Services, vous êtes responsable des éléments suivants :
- Gérer les requêtes et les réponses avec les points de terminaison OAuth 2.0 de Google, y compris les redirections.
- Optimiser l'expérience utilisateur
- Implémentation de fonctionnalités de sécurité pour valider les requêtes et les réponses, et pour prévenir les attaques CSRF.
- Méthodes permettant de confirmer qu'un utilisateur a accordé son consentement pour les niveaux d'accès demandés.
- Gérer les codes d'erreur OAuth 2.0, créer des messages lisibles par les utilisateurs et des liens vers l'aide utilisateur.
En résumé, Google propose la bibliothèque GIS pour vous aider à implémenter rapidement et de manière sécurisée un client OAuth 2.0 et à optimiser l'expérience d'autorisation de l'utilisateur.
Choisir un flux d'autorisation
Vous devrez choisir l'un des deux flux d'autorisation OAuth 2.0 (implicite ou code d'autorisation), que vous décidiez d'utiliser la bibliothèque JavaScript Google Identity Services ou de créer votre propre bibliothèque.
Les deux flux génèrent un jeton d'accès qui peut être utilisé pour appeler les API Google.
Voici les principales différences entre les deux flux :
- le nombre d'actions utilisateur ;
- si votre application appellera les API Google en l'absence de l'utilisateur ;
- si une plate-forme backend est nécessaire pour héberger un point de terminaison et stocker les jetons d'actualisation par utilisateur pour les comptes utilisateur individuels ;
- des niveaux de sécurité utilisateur plus ou moins élevés.
Lorsque vous comparez des flux et évaluez vos exigences de sécurité, vous devez tenir compte du fait que le niveau de sécurité des utilisateurs varie en fonction des autorisations que vous choisissez. Par exemple, l'affichage des invitations d'agenda en lecture seule peut être considéré comme moins risqué que l'utilisation d'un champ d'application en lecture et en écriture pour modifier des fichiers dans Drive.
Comparaison des flux OAuth 2.0
| Flux implicite | Flux avec code d'autorisation | |
| Consentement utilisateur requis | Pour chaque demande de jeton, y compris pour remplacer les jetons expirés. | Uniquement pour la première demande de jeton. |
| L'utilisateur doit être présent | Oui | Non, il est compatible avec l'utilisation hors connexion. |
| Sécurité des utilisateurs | Moins | La plupart d'entre eux disposent d'une authentification client et évitent les risques liés à la gestion des jetons dans le navigateur. |
| Jeton d'accès émis | Oui | Oui |
| Jeton d'actualisation émis | Non | Oui |
| Navigateur compatible requis | Oui | Oui |
| Jeton d'accès utilisé pour appeler les API Google | uniquement à partir d'une application Web exécutée dans le navigateur de l'utilisateur. | soit à partir d'un serveur exécuté sur une plate-forme backend, soit à partir d'une application Web exécutée dans le navigateur de l'utilisateur. |
| Plate-forme de backend requise | Non | Oui, pour l'hébergement et le stockage des points de terminaison. |
| Stockage sécurisé requis | Non | Oui, pour le stockage des jetons d'actualisation. |
| Nécessite l'hébergement d'un point de terminaison de code d'autorisation | Non | Oui, pour recevoir des codes d'autorisation de Google. |
| Comportement d'expiration du jeton d'accès | Un geste de l'utilisateur, comme appuyer sur un bouton ou cliquer sur un lien, est nécessaire pour demander et obtenir un nouveau jeton d'accès valide. | Après une demande initiale de l'utilisateur, votre plate-forme échange le jeton d'actualisation stocké pour obtenir un nouveau jeton d'accès valide, nécessaire pour appeler les API Google. |