Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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.
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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2023/12/01 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2023/12/01 (UTC)."],[[["\u003cp\u003eThis guide helps developers choose between Google Identity Services or a custom JavaScript library for OAuth 2.0 authorization in their web applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Identity Services offers pre-built security features, optimized user experience, and easier implementation compared to building a custom solution.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers need to select between the Implicit or Authorization Code flow based on security, user presence requirements, and backend needs.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization Code flow is recommended for enhanced security, offline access, and refresh token management through a backend server.\u003c/p\u003e\n"],["\u003cp\u003eThe guide assumes prior knowledge of OAuth 2.0 concepts and focuses solely on authorization and data sharing, not user authentication.\u003c/p\u003e\n"]]],[],null,["# Choose a user authorization model\n\nThis guide helps you to choose between using the Google Identity Services\nlibrary for user authorization or implementing your own JavaScript library. It\nhelps you decide which OAuth 2.0 authorization flow is best for your web\napplication.\n\nPrior to reading this guide it is assumed that you are familiar with the terms\nand concepts described in the [Overview](/identity/oauth2/web/guides/overview) and\n[How user authorization works](/identity/oauth2/web/guides/how-user-authz-works) guide.\n\nThe GIS library runs in these [supported browsers](/identity/gsi/web/guides/supported-browsers) on the user's device. It\nis not intended for use with server-side JavaScript frameworks such as Node.js,\ninstead use Google's [Node.js](https://github.com/googleapis/google-api-nodejs-client)\nclient library.\n\nThis guide only covers authorization and data sharing topics. It does not review\nuser authentication, instead see [Sign In With Google](/identity/gsi/web) and the [Migrating\nfrom Google Sign-In](/identity/gsi/web/guides/migration) guide for user sign-up and sign-in.\n\nDeciding if the GIS library is right for you\n--------------------------------------------\n\nYou must choose if using Google's library, or creating your own best fits your\nneeds. An overview of features and functionality:\n\n- Google's Identity Services JavaScript library implements:\n - Popup based consent flows to minimize redirects, thus enabling users to remain on your site throughout the authorization process.\n - Security features such as Cross-site Request Forgery (CRSF).\n - Helper methods to request individual scopes and confirm user consent.\n - Human friendly error handling and documentation links for use by engineers during development and later for visitors to your site.\n- When implementing without the Identity Services library you are responsible for:\n - Managing requests and responses with Google's OAuth 2.0 endpoints, including redirects.\n - Optimizing the user experience.\n - Implementation of security features to validate requests, responses, and to prevent CSRF.\n - Methods to confirm a user has granted consent for any requested scopes.\n - Managing OAuth 2.0 error codes, creating human readable messages, and links to user help.\n\nIn summary, Google offers the GIS library to help you to quickly, and securely\nimplement an OAuth 2.0 client and optimize the user's authorization experience.\n\nChoosing an authorization flow\n------------------------------\n\nYou will need to choose one of two OAuth 2.0 authorization flows: implicit or\nauthorization code -- regardless if you decide to use the Google Identity\nServices JavaScript library or to create your own library.\n\nBoth flows result in an access token which can be used to call Google APIs.\n\nThe primary differences between the two flows are:\n\n- the number of user actions,\n- whether your app will call Google APIs without the user present,\n- if a backend platform is needed to host an endpoint and to store per-user refresh tokens for individual user accounts, and\n- higher or lower levels of user security.\n\nWhen comparing flows and evaluating your security requirements, a factor to\nconsider is that the level of user security varies depending on the scopes you\nchoose. For example, viewing calendar invites as read-only might be considered\nless risky than using a read/write scope to edit files in Drive.\n| **Key Point:** Authorization code flow is recommended because it provides a more secure flow.\n\nOAuth 2.0 flow comparison\n-------------------------\n\n|--------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Implicit flow** | **Authorization code flow** |\n| **User consent required** | For every token request, including replacing expired tokens. | Only for the first token request. |\n| **User must be present** | Yes | No, supports offline use. |\n| **User security** | Least | Most, has client authentication and avoids in-browser token handling risks. |\n| **Access token issued** | Yes | Yes |\n| **Refresh token issued** | No | Yes |\n| **Supported browser required** | Yes | Yes |\n| **Access token used to call Google APIs** | only from a web app running in the user's browser. | either from a server running on backend platform, or from a web app running in the user's browser. |\n| **Requires backend platform** | No | Yes, for endpoint hosting and storage. |\n| **Secure storage needed** | No | Yes, for refresh token storage. |\n| **Requires hosting of an authorization code endpoint** | No | Yes, to receive authorization codes from Google. |\n| **Access token expiration behavior** | A user gesture such as button press or clicking on a link is required to request and obtain a new, valid access token. | After an initial user request, your platform exchanges the stored refresh token to obtain a new, valid access token necessary to call Google APIs. |"]]
