Ce guide vous aide à choisir entre utiliser la bibliothèque Google Identity Services pour l'autorisation des utilisateurs ou implémenter 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 concepts décrits dans les guides Présentation et Fonctionnement de l'autorisation des utilisateurs.
La bibliothèque SIG s'exécute dans les navigateurs compatibles de 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 n'aborde que les sujets liés à l'autorisation et au partage de données. Il ne passe pas en revue l'authentification des utilisateurs. Consultez plutôt les pages Se connecter avec Google et Migrer depuis Google Sign-In pour en savoir plus sur l'inscription et la connexion des utilisateurs.
Décider si la bibliothèque SIG est adaptée à vos besoins
Vous pouvez choisir d'utiliser la bibliothèque de Google ou d'en créer une qui répond le mieux à vos besoins. Présentation des fonctionnalités et du fonctionnement:
- La bibliothèque JavaScript Identity Services de Google implémente :
- Les flux de consentement basés sur des pop-ups permettent de limiter les redirections et de permettre ainsi aux utilisateurs de rester sur votre site tout au long du processus d'autorisation.
- Fonctionnalités de sécurité telles que la falsification des requêtes intersites (CRSF)
- Méthodes d'assistance pour demander des champs d'application individuels et confirmer le consentement de l'utilisateur
- Liens vers la documentation et la gestion des erreurs conviviales par les ingénieurs pendant le développement, puis plus tard pour les visiteurs de votre site.
- Lors de l'implémentation sans la bibliothèque Identity Services, vous êtes responsable des points suivants :
- Gestion des requêtes et des 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 empêcher la requête CSRF
- Méthodes permettant de vérifier qu'un utilisateur a donné son consentement pour tous les champs d'application demandés.
- Gestion des codes d'erreur OAuth 2.0, création de messages lisibles et liens vers l'aide utilisateur
En résumé, Google propose la bibliothèque SIG pour vous aider à implémenter un client OAuth 2.0 de manière rapide et sécurisée, et à optimiser l'expérience d'autorisation de l'utilisateur.
Choisir un flux d'autorisation
Vous devez choisir l'un des deux flux d'autorisation OAuth 2.0: implicite ou avec code d'autorisation, que vous décidiez d'utiliser la bibliothèque JavaScript Google Identity Services ou de créer votre propre bibliothèque.
Ces deux flux génèrent un jeton d'accès qui peut être utilisé pour appeler les API Google.
Les principales différences entre les deux flux sont les suivantes:
- le nombre d'actions utilisateur,
- si votre application appelle les API Google sans la présence de l'utilisateur,
- si une plate-forme backend est nécessaire pour héberger un point de terminaison et stocker des jetons d'actualisation par utilisateur pour chaque compte utilisateur ; et
- des niveaux supérieurs ou inférieurs de sécurité des utilisateurs.
Lorsque vous comparez les flux et évaluez vos exigences de sécurité, tenez compte du fait que le niveau de sécurité utilisateur varie en fonction des champs d'application que vous choisissez. Par exemple, il peut être considéré comme moins risqué d'afficher les invitations d'agenda en lecture seule que d'utiliser un niveau d'accès en lecture/écriture pour modifier des fichiers dans Drive.
Comparaison des flux OAuth 2.0
| Flux implicite | Flux du code d'autorisation | |
| Consentement de l'utilisateur requis | Pour chaque demande de jeton, y compris le remplacement de jetons expirés. | Uniquement pour la première requête de jeton. |
| L'utilisateur doit être présent | Oui | Non, disponible hors connexion. |
| Sécurité de l'utilisateur | Valeurs les moins fréquentes | La plupart, authentifie le client et évite les risques de 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 s'exécutant sur une plate-forme backend, soit à partir d'une application Web exécutée dans le navigateur de l'utilisateur. |
| Nécessite une plate-forme backend | Non | Oui, pour l'hébergement et le stockage de points de terminaison. |
| Stockage sécurisé nécessaire | 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 lié à l'expiration du jeton d'accès | Un geste de l'utilisateur, tel qu'une pression sur un bouton ou un clic sur un lien, est nécessaire pour demander et obtenir un nouveau jeton d'accès valide. | Après une requête utilisateur initiale, votre plate-forme échange le jeton d'actualisation stocké afin d'obtenir un nouveau jeton d'accès valide nécessaire pour appeler les API Google. |