Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Étapes à suivre pour minimiser l'impact des modifications de champ d'application sur les utilisateurs
Si votre application nécessite l'adresse e-mail d'un utilisateur authentifié et que vous avez déjà utilisé profile.emails.read à cette fin, utilisez plutôt email.
Révoquez le jeton utilisateur précédent pour le champ d'application à supprimer ou supprimez complètement l'accès à l'application. Par exemple, un jeton avec l'accès profile.emails.read doit être révoqué. Nous vous recommandons d'appliquer la révocation lorsque vos utilisateurs se trouvent dans votre application afin de pouvoir obtenir leur consentement immédiatement.
Demandez à vos utilisateurs de donner à nouveau leur consentement avec le nouveau champ d'application, par exemple email, sans profile.emails.read.
Supprimez le champ d'application qui doit être abandonné de la configuration de l'écran de consentement OAuth de vos API Google.
Pour migrer votre application de Google+ Sign-In vers Google Sign-In, vous devez mettre à jour votre bouton de connexion, les champs d'application demandés et les instructions pour récupérer les informations de profil auprès de Google. Pour obtenir des instructions complètes, consultez la documentation de Google Sign-In pour Android.
Lorsque vous mettez à jour votre bouton de connexion, ne faites pas référence à G+ et n'utilisez pas le rouge.
Respectez nos consignes relatives à la marque mises à jour.
La plupart des applications Google+ Sign-In demandaient une combinaison des champs d'application suivants : plus.login, plus.me et plus.profile.emails.read. En utilisant GoogleSignInOptions.Builder avec l'option DEFAULT_SIGN_IN, vous demandez automatiquement l'étendue profile, qui fournit le nom et la photo de profil de l'utilisateur. Si vous souhaitez également obtenir l'adresse e-mail de l'utilisateur, vous devez appeler .requestEmail() lors de la création des options de connexion Google.
De nombreux implémentateurs de Google+ Sign-In ont utilisé le flux de code. Cela signifie que les applications Android, iOS ou JavaScript obtiennent un code d'autorisation OAuth auprès de Google, et que le client renvoie ce code au serveur, avec une protection contre la falsification des requêtes intersites. Le serveur valide ensuite le code et obtient des jetons d'actualisation et d'accès pour extraire les informations de profil utilisateur de l'API people.get.
Google vous recommande désormais de demander un jeton d'ID et de l'envoyer depuis votre client vers votre serveur. Les jetons d'identification sont dotés d'une protection intégrée contre la falsification intersites et peuvent également être validés de manière statique sur votre serveur, ce qui évite un appel d'API supplémentaire pour obtenir des informations sur le profil utilisateur à partir des serveurs de Google. Suivez les instructions pour valider les jetons d'identification sur votre serveur.
Si vous préférez toujours utiliser le flux de code pour obtenir des informations de profil, vous pouvez le faire. Une fois que votre serveur dispose d'un jeton d'accès, vous devez obtenir des informations sur le profil utilisateur à partir des points de terminaison userinfo spécifiés dans notre document de découverte sur la connexion. La réponse de l'API est mise en forme différemment de la réponse du profil Google+. Vous devez donc mettre à jour votre analyse pour utiliser le nouveau format.
Si vous utilisez GoogleAuthUtil.getToken ou Plus.API, vous devez migrer vers la dernière API Sign-In pour plus de sécurité et une meilleure expérience utilisateur.
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 2024/11/09 (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 2024/11/09 (UTC)."],[[["\u003cp\u003eGoogle Sign-In for Android is outdated; migrate to Credential Manager for enhanced security and user experience, except for Wear OS 3, 4, and 5.0, which should continue using Google Sign-In for Android until Credential Manager support is available.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eprofile.emails.read\u003c/code\u003e scope is now sensitive; replace it with the \u003ccode\u003eemail\u003c/code\u003e scope and follow provided steps to avoid user disruption and security warnings.\u003c/p\u003e\n"],["\u003cp\u003eGoogle+ Sign-In is fully deprecated; migrate to Google Sign-In and update sign-in elements according to the new branding guidelines.\u003c/p\u003e\n"],["\u003cp\u003eFor server-side authentication, Google recommends using ID tokens instead of the code flow for better security and efficiency.\u003c/p\u003e\n"]]],[],null,["# Migrate from Google+ sign-in\n\n| **Warning:** Google Sign-In for Android is outdated and no longer supported. To ensure the continued security and usability of your app, [migrate\n| to Credential Manager](https://developer.android.com/training/sign-in/credential-manager/) today. Credential Manager supports passkey, password, and federated identity authentication (such as Sign-in with Google), stronger security, and a more consistent user experience. For Wear developers: Credential Manager will be supported in Wear OS 5.1 and later on selected watches. Developers actively supporting Wear OS 3, 4 and 5.0 devices with Sign in with Google should continue using Google Sign-in for Android for your Wear applications. Sign in with Google support will be available on Credential Manager APIs for these versions of WearOS at a later date.\n| **Important:** The scope\n| `profile.emails.read` is now classified as a\n| [sensitive scope](https://support.google.com/cloud/answer/9110914#sensitive-scope-verification).\n| You can achieve the same functionality with the OpenID Connect (OIDC) scope\n| of `email`. To minimize impact on your users, complete the\n| [steps](#steps) in this guide.\n|\n| If you don't complete these steps, any user with an active token that still\n| has access to the scope that we have phased out might be shown an\n| [unverified app screen or \"Sign-in disabled\" message](https://support.google.com/cloud/answer/9110914#verified-but-app-disabled)\n| and receive a Security Center warning to\n| [remove risky access](https://support.google.com/accounts/answer/3466521)\n| to their data. This occurs because the user has an active token where the\n| API scope is no longer verified. If your application doesn't revoke the\n| token as described in the prescribed [steps](#steps), the user\n| might continue to receive a warning.\n\nSteps to minimize the impact of scope changes on users\n------------------------------------------------------\n\n1. If your application requires the email address of an authenticated user, and you've previously used `profile.emails.read` for that purpose, use `email` instead.\n2. Obtain approval for `profile.emails.read` with an approved verification request. Refer to [How do I submit for verification?](https://support.google.com/cloud/answer/9110914#submit-howto)\n3. [Revoke](/identity/protocols/oauth2/native-app#tokenrevoke) the prior user token to the scope that's to be removed or remove access to the application entirely. For example, a token with `profile.emails.read` access should be revoked. We recommend you apply the revocation while your users are in your application so that you can get user consent immediately.\n4. Prompt your users to re-consent with the new scope, such as `email`, without `profile.emails.read`.\n5. Remove the scope that's to be phased out of your Google APIs OAuth consent screen configuration.\n\n| The Google+ Sign-in feature has been fully deprecated as of March 7, 2019.\n|\n| Developers should migrate to the more comprehensive\n| [Google Sign-in](/identity/sign-in/android) authentication system.\n|\n| Migration tips are also available for\n| [Web](/identity/sign-in/web/quick-migration-guide).\n\nTo migrate your app from Google+ Sign-In to Google Sign-In, you need to\nupdate your sign-in button, requested scopes, and instructions on how to\nretrieve profile information from Google. Follow our\n[Google Sign In for Android documentation](/identity/sign-in/android/legacy-sign-in)\nfor full instructions.\n\nWhen you update your sign-in button, do not refer to G+ or use the color red.\nConform to our updated [branding guidelines](/identity/branding-guidelines).\n\nMost Google+ Sign-In applications requested some combination of the scopes:\n`plus.login`, `plus.me` and `plus.profile.emails.read`. By using\n`GoogleSignInOptions.Builder` with the `DEFAULT_SIGN_IN` option, you will\nautomatically request the `profile` scope which provides the user's name and\nprofile picture. If you also want the user's email address, you should call\n`.requestEmail()` when constructing Google sign-in options.\n\nMany implementers of Google+ Sign-In used the\n[code flow](/identity/protocols/oauth2/native-app#handlingresponse). This means\nthat the Android, iOS or JavaScript apps obtain an OAuth authorization code from\nGoogle, and the client sends that code back to the server, along with cross-site\nrequest forgery protection. The server then validates the code and obtains\nrefresh and access tokens to pull user profile information from the `people.get`\nAPI.\n\nGoogle now recommends that you request an ID token and send the ID token from\nyour client to your server. ID tokens have cross-site forgery protections\nbuilt-in and also can be statically verified on your server, which avoids an\nextra API call to get user profile information from Google's servers. Follow the\ninstructions to\n[validate ID tokens on your server](/identity/sign-in/android/backend-auth#verify-the-integrity-of-the-id-token).\n\nIf you still prefer to use the code flow to obtain profile information,\nyou may do so. Once your server has an access token, you need to\n[obtain user profile information](/identity/protocols/oauth2/openid-connect#obtaininguserprofileinformation)\nfrom the `userinfo` endpoints specified in our Sign-In\n[Discovery document](/identity/protocols/oauth2/openid-connect#discovery). The\nAPI response is formatted differently than the Google+ profile response, so you\nneed to update your parsing to the new format.\n\nIf you are using `GoogleAuthUtil.getToken` or `Plus.API`, you should\n[migrate](/identity/sign-in/android/migration-guide)\nto the newest Sign-In API for greater security and a better user experience."]]
