# Migrate from Google+ sign-in

> [!WARNING]
> **Warning:** Google Sign-In for Android is outdated and no longer supported. To ensure the continued security and usability of your app, [migrate
> 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.

> [!CAUTION]
> **Important:** The scope
> `profile.emails.read` is now classified as a
> [sensitive scope](https://support.google.com/cloud/answer/9110914#sensitive-scope-verification).
> You can achieve the same functionality with the OpenID Connect (OIDC) scope
> of `email`. To minimize impact on your users, complete the
> [steps](https://developers.google.com/identity/sign-in/android/quick-migration-guide#steps) in this guide.
>
> If you don't complete these steps, any user with an active token that still
> has access to the scope that we have phased out might be shown an
> [unverified app screen or "Sign-in disabled" message](https://support.google.com/cloud/answer/9110914#verified-but-app-disabled)
> and receive a Security Center warning to
> [remove risky access](https://support.google.com/accounts/answer/3466521)
> to their data. This occurs because the user has an active token where the
> API scope is no longer verified. If your application doesn't revoke the
> token as described in the prescribed [steps](https://developers.google.com/identity/sign-in/android/quick-migration-guide#steps), the user
> might continue to receive a warning.

## Steps to minimize the impact of scope changes on users

1. 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.
2. 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)
3. [Revoke](https://developers.google.com/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.
4. Prompt your users to re-consent with the new scope, such as `email`, without `profile.emails.read`.
5. Remove the scope that's to be phased out of your Google APIs OAuth consent screen configuration.

> [!WARNING]
> The Google+ Sign-in feature has been fully deprecated as of March 7, 2019.
>
> Developers should migrate to the more comprehensive
> [Google Sign-in](https://developers.google.com/identity/sign-in/android) authentication system.
>
> Migration tips are also available for
> [Web](https://developers.google.com/identity/sign-in/web/quick-migration-guide).

To migrate your app from Google+ Sign-In to Google Sign-In, you need to
update your sign-in button, requested scopes, and instructions on how to
retrieve profile information from Google. Follow our
[Google Sign In for Android documentation](https://developers.google.com/identity/sign-in/android/legacy-sign-in)
for full instructions.

When you update your sign-in button, do not refer to G+ or use the color red.
Conform to our updated [branding guidelines](https://developers.google.com/identity/branding-guidelines).

Most Google+ Sign-In applications requested some combination of the scopes:
`plus.login`, `plus.me` and `plus.profile.emails.read`. By using
`GoogleSignInOptions.Builder` with the `DEFAULT_SIGN_IN` option, you will
automatically request the `profile` scope which provides the user's name and
profile picture. If you also want the user's email address, you should call
`.requestEmail()` when constructing Google sign-in options.

Many implementers of Google+ Sign-In used the
[code flow](https://developers.google.com/identity/protocols/oauth2/native-app#handlingresponse). This means
that the Android, iOS or JavaScript apps obtain an OAuth authorization code from
Google, and the client sends that code back to the server, along with cross-site
request forgery protection. The server then validates the code and obtains
refresh and access tokens to pull user profile information from the `people.get`
API.

Google now recommends that you request an ID token and send the ID token from
your client to your server. ID tokens have cross-site forgery protections
built-in and also can be statically verified on your server, which avoids an
extra API call to get user profile information from Google's servers. Follow the
instructions to
[validate ID tokens on your server](https://developers.google.com/identity/sign-in/android/backend-auth#verify-the-integrity-of-the-id-token).

If you still prefer to use the code flow to obtain profile information,
you may do so. Once your server has an access token, you need to
[obtain user profile information](https://developers.google.com/identity/protocols/oauth2/openid-connect#obtaininguserprofileinformation)
from the `userinfo` endpoints specified in our Sign-In
[Discovery document](https://developers.google.com/identity/protocols/oauth2/openid-connect#discovery). The
API response is formatted differently than the Google+ profile response, so you
need to update your parsing to the new format.

If you are using `GoogleAuthUtil.getToken` or `Plus.API`, you should
[migrate](https://developers.google.com/identity/sign-in/android/migration-guide)
to the newest Sign-In API for greater security and a better user experience.