Google+ shutdown will break OAuth provider

[Tratcher]

The Authentication.Google package implements OAuth2 with Google services. However, it uses Google+ to fetch additional user information.
https://github.com/aspnet/AspNetCore/blob/5ab3c89be3e6342f2a39c666fd0aca708fc7ec8b/src/Security/Authentication/Google/src/GoogleDefaults.cs#L21
https://github.com/aspnet/AspNetCore/blob/5ab3c89be3e6342f2a39c666fd0aca708fc7ec8b/src/Security/Authentication/Google/src/GoogleOptions.cs#L29-L34

"The Google+ Sign-in feature is fully deprecated and is being shut down on March 7, 2019. This will be a progressive shutdown, with intermittent failures starting as early as January 28, 2019. Developers should migrate to the more comprehensive Google Sign-in authentication system." ~https://developers.google.com/+/web/signin/

This is a patch candidate all the way down to 1.0 and Katana. @muratg @blowdart

Proposals:

• Find a new API that will give us basic information like name, e-mail, etc.. It's unlikely the transition would be seamless.
• Deprecate the provider and show people how to use OpenIdConnect. This has the benefit of being a docs only change. It may not work for Katana though, we'll have to see if it supported enough ODIC features.

[jamesgurung]

The scopes requested by default are:

• openid
• email
• profile
• https://www.googleapis.com/auth/userinfo.email
• https://www.googleapis.com/auth/userinfo.profile
• https://www.googleapis.com/auth/plus.me

It seems like it's just the last one which is connected with Google+. Is the fix as simple as removing this scope? I don't think the default auth flow even uses it?

This would be a breaking change, but most common use cases are covered by the other scopes - and it's going to break anyway when Google+ is shut down.

[Tratcher]

It's the call out to https://www.googleapis.com/plus/v1/people/me that's really going to break. That's where we get names, e-mails, etc.. We need to find a replacement.

[hempels]

I expect you can simply replace the call to /plus/v1/people/me with a call to /userinfo/v2/me.

It should return a response comparable to the one returned by the deprecated + API and not require any further changes (aside from removing the plus.me scope.)

https://developers.google.com/apis-explorer/#search/userinfo/m/oauth2/v2/oauth2.userinfo.v2.me.get

Alternatively, you can skip that call if using their TokenInfo endpoint to handle token validation. If the email and profile scopes are included, it automatically returns those fields.

[rhubrightj]

Pardon my ignorance on the subject.... but where do I find this call in an asp.net web api project? I'm only using token validation.

I know I'm using it somewhere, according to google I'm sending calls to plus.people.get

I do have reference to Microsoft.Owin.Security.Google

[theaswanson]

Pardon my ignorance on the subject.... but where do I find this call in an asp.net web api project? I'm only using token validation.

I know I'm using it somewhere, according to google I'm sending calls to plus.people.get

I do have reference to Microsoft.Owin.Security.Google

If you're using ASP.Net Core 2.2, you might have the following code in your Startup.cs file which makes use of the OAuth provider (taken from https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/google-logins?view=aspnetcore-2.2):

services.AddAuthentication().AddGoogle(googleOptions => { googleOptions.ClientId = Configuration["Authentication:Google:ClientId"]; googleOptions.ClientSecret = Configuration["Authentication:Google:ClientSecret"]; });

I'm currently using this and am affected by this issue.

[rhubrightj]

Definitely a breaking change on my site... I hope it's as simple as just updating Microsoft.Owin.Security.Google NuGet pkg when they are able to update it.

[ThoughtHopper]

Yup this will break our stuff.
Google has really screwed us up by pushing the date to end of march.

I tried changing the endpoints to the ones given back by the well-known configuration:
https://accounts.google.com/.well-known/openid-configuration

The current code works until it tries to retrieve the userinfo.
The response is not the same format as the response given by google+ apis.

For users like us, we do not really need to poke the userinfo endpoint, the id_token already contains information about the user. I guess in some cases it may be easier to poke the user endpoint than to actually verify the id_token.

I hope there is an answer soon from the owners of the project, Google has threaten to start failing requests as early as January 28,2019.

[muratg]

cc @DamianEdwards @Eilon @davidfowl FYI.