Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Lorsque vous demandez à l'utilisateur l'autorisation d'accéder à ses données ou à d'autres ressources, vous pouvez demander tous les champs d'application d'emblée dans la requête initiale ou n'en demander que ceux dont vous avez besoin, à l'aide de l'autorisation incrémentielle.
À l'aide d'une autorisation incrémentielle, votre application ne demande initialement que les niveaux d'accès requis pour démarrer votre application, puis demande des champs d'application supplémentaires lorsque de nouvelles autorisations sont requises, dans un contexte qui indique le motif de la demande à l'utilisateur.
Par exemple, supposons que votre application permette aux utilisateurs d'enregistrer des playlists musicales dans Google Drive. Votre application peut demander des informations utilisateur de base lors de la connexion, puis, lorsque l'utilisateur est prêt à enregistrer sa première playlist, ne demander que des autorisations Google Drive.
Utilisez cette technique si vous pensez que les utilisateurs ne se connectent pas parce que votre écran de consentement est trop chargé ou qu'ils ne comprennent pas pourquoi certaines autorisations leur sont demandées.
Les instructions suivantes sont destinées au Web et sont issues de celles pour ajouter un bouton de connexion côté client : Créer un bouton de connexion Google 2.0.
Pour en savoir plus sur l'autorisation incrémentielle pour le Web, consultez la documentation OAuth 2.0.
Demander des champs d'application supplémentaires
Lors de la connexion, votre application demande des champs d'application de base, qui consistent en le champ d'application de connexion profile, ainsi que tous les autres champs d'application initiaux dont votre application a besoin pour fonctionner.
Par la suite, lorsque l'utilisateur souhaite effectuer une action nécessitant des champs d'application supplémentaires, votre application demande ces champs d'application supplémentaires, et l'utilisateur n'autorise que les nouveaux champs d'application à partir d'un écran d'autorisation.
Étape 1: Demandez des champs d'application de base
Demandez la portée de base profile lorsque vous initialisez Google Sign-In. Cette étape est incluse dans la section Créer un bouton de connexion Google 2.0.
auth2=gapi.auth2.init({client_id:'CLIENT_ID.apps.googleusercontent.com',cookiepolicy:'single_host_origin',/** Default value **/scope:'profile'});/** Base scope **/
Étape 2: Demandez des champs d'application supplémentaires
Lorsque des portées supplémentaires sont nécessaires, demandez-les en créant un compilateur d'options avec les portées que vous souhaitez ajouter, puis en appelant user.grant({scope:
[OPTIONS BUILDER]}).then(successFunction, failFunction);:
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 2025/07/25 (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 2025/07/25 (UTC)."],[[["\u003cp\u003eThe Google Sign-In JavaScript Platform Library is deprecated; developers should migrate to the Google Identity Services library for user authorization and access tokens.\u003c/p\u003e\n"],["\u003cp\u003eFedCM APIs will become mandatory for the Google Sign-In library, requiring developers to conduct an impact assessment.\u003c/p\u003e\n"],["\u003cp\u003eIncremental authorization allows developers to request user permissions in stages, starting with basic scopes and requesting additional scopes as needed, improving user experience.\u003c/p\u003e\n"],["\u003cp\u003eTo implement incremental authorization, request the 'profile' scope initially and add further scopes like 'email' or 'drive' using \u003ccode\u003egapi.auth2.SigninOptionsBuilder\u003c/code\u003e and \u003ccode\u003euser.grant()\u003c/code\u003e when required.\u003c/p\u003e\n"]]],[],null,["# Requesting additional permissions\n\n| **Warning:** The Google Sign-In library optionally uses FedCM APIs, and their use will become a requirement. [Conduct an impact assessment](/identity/sign-in/web/gsi-with-fedcm) to confirm that user sign-in continues to function as expected. \n|\n| Support for the Google Sign-In library is deprecated, see the [Deprecation and Sunset](/identity/sign-in/web/deprecation-and-sunset) guide for more.\n| **Warning:** We are [discontinuing the Google Sign-In JavaScript Platform Library for web](https://developers.googleblog.com/2021/08/gsi-jsweb-deprecation.html). For user authorization and to obtain access tokens for use with Google APIs, use the newer [Google Identity Services JavaScript library](/identity/oauth2/web/guides/overview) instead. For existing implementations see [Migrate to Google Identity Services](/identity/oauth2/web/guides/migration-to-gis).\n\nWhen requesting user permission to access user data or other\nresources, you can request all scopes up-front in the initial request or\nrequest scopes only as needed, using *incremental authorization*.\nUsing incremental authorization, your app initially requests only the scopes\nrequired to start your app, then requests additional scopes as new permissions\nare required, in a context that identifies the reason for the request to the\nuser.\n\nFor example, suppose your app lets users save music playlists\nto Google Drive; your app can request basic user information at sign-in,\nand later, when the user is ready to save their first playlist,\nask only for Google Drive permissions.\n\nUse this technique if you suspect users are not signing in because your\nconsent screen is overwhelming, or are confused about why they are being asked\nfor certain permissions.\nThe following instructions are for the web, and are derived from the\ninstructions for adding a client-side sign-in button:\n[Building a Google 2.0 Sign-In button](/identity/sign-in/web/build-button).\nYou can read more about incremental authorization for the web in the\n[OAuth 2.0 documentation](/identity/protocols/oauth2/web-server#incrementalAuth).\n\nRequesting additional scopes\n----------------------------\n\nAt sign-in, your app requests \"base\" scopes, consisting of the sign-in scope\n`profile` plus any other initial scopes your app requires for operation.\nLater, when the user wants to perform an action that requires additional\nscopes, your app requests those additional scopes and the user authorizes only\nthe new scopes from a consent screen.\n\n### Step 1: Request base scopes\n\nRequest the base scope `profile` when you initialize Google Sign-In. This\nstep is included in\n[Building a Google 2.0 Sign-In button](/identity/sign-in/web/build-button). \n\n auth2 = gapi.auth2.init({\n client_id: 'CLIENT_ID.apps.googleusercontent.com',\n cookiepolicy: 'single_host_origin', /** Default value **/\n scope: 'profile' }); /** Base scope **/\n\n### Step 2: Request additional scopes\n\nWherever additional scopes are needed, request them by constructing an options\nbuilder with the scopes you want to add and then calling `user.grant({scope:\n[OPTIONS BUILDER]}).then(successFunction, failFunction);`: \n\n const options = new gapi.auth2.SigninOptionsBuilder();\n options.setScope('email https://www.googleapis.com/auth/drive');\n\n googleUser = auth2.currentUser.get();\n googleUser.grant(options).then(\n function(success){\n console.log(JSON.stringify({message: \"success\", value: success}));\n },\n function(fail){\n alert(JSON.stringify({message: \"fail\", value: fail}));\n });"]]