Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les applications Web doivent obtenir un jeton d'accès pour appeler les API Google de manière sécurisée.
La bibliothèque JavaScript Google Identity Services est compatible à la fois avec l'authentification pour la connexion des utilisateurs et pour l'autorisation d'obtenir un jeton d'accès à utiliser avec les API Google. La bibliothèque est conçue uniquement pour être utilisée dans les navigateurs.
L'authentification permet d'identifier une personne. On parle communément d'inscription ou de connexion d'utilisateur. L'autorisation est le processus d'attribution ou de refus de l'accès aux données ou aux ressources. Elle inclut l'obtention et la gestion du consentement des utilisateurs, la limitation de la quantité de données ou de ressources partagées avec les niveaux d'accès, et la récupération d'un jeton d'accès à utiliser avec les API Google.
Ces guides couvrent des sujets liés à l'autorisation et au partage des données.
Si vous avez besoin d'aide concernant l'authentification ou la mise en œuvre de l'inscription et de la connexion des utilisateurs, consultez Se connecter avec Google.
Cette bibliothèque 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.
Modifications apportées
Pour les utilisateurs, la bibliothèque Google Identity Services offre de nombreuses améliorations de facilité d'utilisation par rapport aux bibliothèques JavaScript précédentes, par exemple:
L'authentification pour la connexion des utilisateurs et l'autorisation d'obtenir un jeton d'accès pour appeler les API Google comportent désormais deux parcours utilisateur distincts : l'un pour la connexion et l'autre pour le consentement lors de l'autorisation, avec des parcours utilisateur distincts permettant de différencier clairement qui vous êtes et ce qu'une application peut faire.
Boîtes de dialogue pop-up dans le navigateur pour réduire les frictions et qui ne nécessitent pas que les utilisateurs quittent votre site pour :
obtenir un jeton d'accès auprès de Google ;
et envoyer un code d'autorisation à votre plate-forme backend.
Pour les développeurs, notre objectif a été de réduire la complexité, d'améliorer la sécurité et de rendre votre intégration aussi rapide et facile que possible. Voici quelques-unes de ces modifications:
L'authentification utilisateur pour la connexion et l'autorisation permettant d'obtenir un jeton d'accès permettant d'appeler les API Google sont deux ensembles distincts d'objets JavaScript et de méthodes. Cela simplifie et simplifie la mise en œuvre de l'authentification ou de l'autorisation.
Une seule bibliothèque JavaScript est désormais compatible avec :
Flux implicite OAuth 2.0 permettant d'obtenir un jeton d'accès à utiliser dans le navigateur
Le flux avec code d'autorisation OAuth 2.0, également appelé accès hors connexion, permet de transmettre de manière sécurisée un code d'autorisation à votre plate-forme de backend, où il peut être échangé contre un jeton d'accès et un jeton d'actualisation. Auparavant, ces flux n'étaient disponibles qu'en utilisant plusieurs bibliothèques et via des appels directs aux points de terminaison OAuth 2.0. Avec une seule bibliothèque, vous réduisez le temps et les efforts d'intégration. Au lieu d'inclure et d'apprendre plusieurs bibliothèques et concepts OAuth 2.0, vous pouvez vous concentrer sur une interface unifiée.
L'indirection via les fonctions de style getter a été supprimée pour plus de simplicité et de lisibilité.
Lorsque vous gérez les réponses d'autorisation, vous choisissez d'utiliser ou non une promesse pour traiter les requêtes, plutôt que de prendre cette décision à votre place.
Le module gapi.auth2 ainsi que les objets et méthodes associés ne sont plus chargés automatiquement en arrière-plan. Ils ont été remplacés par des objets et des méthodes plus explicites de la bibliothèque Google Identity Services.
L'actualisation automatique des jetons d'accès expirés a été supprimée afin de renforcer la sécurité des utilisateurs. Une fois qu'un jeton d'accès a expiré, votre application doit gérer les réponses d'erreur de l'API Google, demander et obtenir un nouveau jeton d'accès valide.
Pour assurer une séparation claire des moments d'authentification et d'autorisation, il n'est plus possible de connecter un utilisateur à votre application et à son compte Google simultanément tout en émettant un jeton d'accès. Auparavant, la requête d'un jeton d'accès connectait également les utilisateurs à leur compte Google et renvoyait des identifiants de jeton d'ID JWT pour l'authentification des utilisateurs.
Pour améliorer la sécurité et la confidentialité des utilisateurs, les identifiants utilisateur émis pour l'autorisation respectent le principe du moindre privilège en n'incluant qu'un jeton d'accès et les informations nécessaires à sa gestion.
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).
[null,null,["Dernière mise à jour le 2023/12/01 (UTC)."],[[["\u003cp\u003eGoogle Identity Services JavaScript library enables secure access to Google APIs via access tokens and supports user authentication.\u003c/p\u003e\n"],["\u003cp\u003eThe library offers separate, streamlined user flows for sign-in (authentication) and consent (authorization) for enhanced user experience and control.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers benefit from reduced complexity, improved security, and easier integration with features like a unified library for both implicit and authorization code flows.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Identity Services prioritizes user privacy and security through measures like least privilege credentials and explicit access token refresh handling.\u003c/p\u003e\n"],["\u003cp\u003eThe library is exclusively for browser-based applications and should not be used with server-side JavaScript frameworks like Node.js.\u003c/p\u003e\n"]]],[],null,["# Authorizing for Web\n\nWeb apps must obtain an access token to securely call Google APIs.\n\nThe Google Identity Services JavaScript library supports both authentication for\nuser sign-in and authorization to obtain an access token for use with Google\nAPIs. The library is intended only for use in browsers.\n\nAuthentication establishes who someone is, and is commonly referred to as user\nsign-up or sign-in. Authorization is the process of granting or rejecting access\nto data or resources. It includes obtaining and managing user consent, limiting\nthe amount of data or resources shared with scopes, and retrieving an access\ntoken for use with Google APIs.\n\nThese guides cover authorization and data sharing topics.\n\n[How user authorization works](/identity/oauth2/web/guides/how-user-authz-works) describes the individual steps of user\nauthorization in detail and includes user dialog examples.\n\nIf you are looking for help with authentication and how to implement user\nsign-up and sign-in see [Sign In With Google](/identity/gsi/web/guides/overview).\n| **Note:** The `email`, `profile`, and `openid` scopes are used for user authentication. If your app only uses these scopes [Sign In With Google](/identity/gsi/web) is recommended instead.\n\nThis library is not intended for use with server-side JavaScript frameworks such\nas Node.js, instead use Google's [Node.js](https://github.com/googleapis/google-api-nodejs-client)\nclient library.\n\nWhat's changed\n--------------\n\nFor users, the Google Identity Services library offers numerous usability\nimprovements over earlier JavaScript libraries, including:\n\n- Authentication for user sign-in, and authorization to obtain an access token to call Google APIs, now have two separate and distinct user flows; one for [sign-in](/identity/gsi/web/guides/overview#how_it_works) and another for [consent](/identity/oauth2/web/guides/how-user-authz-works#user_consent) during authorization, with separate user flows to clearly differentiate who you are, from what an app can do.\n- Improved visibility and granular control of data sharing during [user\n consent](/identity/oauth2/web/guides/how-user-authz-works#user_consent).\n- Browser based pop-up dialogs to reduce friction, and which do not require users to leave your site to:\n - obtain an access token from Google, or\n - send an authorization code to your backend platform.\n\nFor developers, our focus has been to reduce complexity, improve security, and\nmake your integration as quick and easy as possible. Some of these changes are:\n\n- User [authentication](/identity/gsi/web/reference/js-reference) for sign-in, and [authorization](/identity/oauth2/web/reference/js-reference) used to obtain an access token to call Google APIs, are two separate and distinct sets of JavaScript objects, and methods. This reduces the complexity and amount of detail required to implement authentication or authorization.\n- A single JavaScript library now supports both the:\n - OAuth 2.0 implicit flow, used to obtain an access token for use in-browser\n - OAuth 2.0 authorization code flow, also known as offline access, and initiates securely delivering an authorization code to your backend platform, where it can be exchanged for an access token and refresh token. Previously, these flows were only available by using multiple libraries and through direct calls to OAuth 2.0 endpoints. A single library decreases your integration time and effort, instead of including and learning multiple libraries and OAuth 2.0 concepts you can focus on a single, unified interface.\n- Indirection through getter style functions has been removed for simplicity and readability.\n- When handling authorization responses you choose whether or not to use a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) to fulfill requests, instead of that decision being made for you.\n- The [Google API Client Library for JavaScript](https://github.com/google/google-api-javascript-client) has been updated with these changes:\n - the `gapi.auth2` module and associated objects and methods are no longer automatically loaded for you behind the scenes, and have been replaced with more explicit Google Identity Services library objects and methods.\n - Automatic refresh of expired access tokens has been removed to improve user security and awareness. After an access token expires your app must handle Google API error responses, request, and obtain a new, valid access token.\n - To support a clear separation of authentication and authorization moments, simultaneously signing a user in to your app and to their Google Account while also issuing an access token is no longer supported. Previously, requesting an access token also signed users into their Google Account and returned a JWT ID token credential for user authentication.\n- To increase user security and privacy, per user [credentials](/identity/oauth2/web/guides/migration-to-gis#example_credentials) issued for authorization follow the principle of least privilege by including only an access token and information required to manage it."]]
