Google+ shutdown impacts

[fhtino]

As far as I can understand, I suppose this library will be impacted by Google+ API shutdown on March, 7 2019. Like AspNetCore, Katana uses deprecated API URL, like "https://www.googleapis.com/plus/v1/people/me"
Issue opened on AspNet core: dotnet/aspnetcore#6069

[rhubrightj]

Definitely a breaking change on my site... I hope it's as simple as just updating Microsoft.Owin.Security.Google NuGet pkg.

[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 endpoints 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.
Fails @ GoogleOAuth2AuthenticatedContext constructor parsing the givenName

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.

Anyway, 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.

[luronumen]

Hi @Tratcher

Could you please comment this issue? Is there any possibility to fix it thru the Microsoft.Owin.Security.Google NuGet package?
For more details about this issue you can check:

• Google+ API Shutdown
• Migrate from Google+ Sign-In
• Add Google Sign-In to Your Web App

Thanks in advance!

[fhtino]

Perhaps a couple of small changes could solve the issue.

In Microsoft.Owin.Security.Google.Constants

...
internal const string UserInformationEndpoint = "https://www.googleapis.com/userinfo/v2/me";   //OLD:"https://www.googleapis.com/plus/v1/people/me";
...

In Microsoft.Owin.Security.Google.GoogleOAuth2AuthenticatedContext

public GoogleOAuth2AuthenticatedContext(IOwinContext context, JObject user, string accessToken, string refreshToken, string expires)
...and...
public GoogleOAuth2AuthenticatedContext(IOwinContext context, JObject user, JObject tokenResponse)

{
...
// **** NEW ***
Id = TryGetValue(user, "id");
Name = TryGetValue(user, "name");
GivenName = TryGetValue(user, "given_name");
FamilyName = TryGetValue(user, "family_name");
Profile = TryGetValue(user, "link");
Email = TryGetValue(user, "email");

// *** OLD ***
//Id = TryGetValue(user, "id");
//Name = TryGetValue(user, "displayName");
//GivenName = TryGetValue(user, "name", "givenName");
//FamilyName = TryGetValue(user, "name", "familyName");
//Profile = TryGetValue(user, "url");
//Email = TryGetFirstValue(user, "emails", "value"); 
}

I tried the new code. The "id" and the other fields are filled with the same values. It seems backward compatible. The ClaimsIdentitity is filled with the same values.

[Tratcher]

Here's a temporary workaround. I tested it with 4.0 but it should also work with 3.1.

            app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
            {
                ClientId = Environment.GetEnvironmentVariable("google:clientid"),
                ClientSecret = Environment.GetEnvironmentVariable("google:clientsecret"),
                UserInformationEndpoint = "https://www.googleapis.com/oauth2/v2/userinfo",
                BackchannelHttpHandler = new GoogleUserInfoRemapper(new WebRequestHandler())
            });

using System;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;
using Newtonsoft.Json.Linq;

namespace Katana.Sandbox.WebServer
{
    internal class GoogleUserInfoRemapper : DelegatingHandler
    {
        public GoogleUserInfoRemapper(HttpMessageHandler innerHandler) : base(innerHandler) { }

        protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            var response = await base.SendAsync(request, cancellationToken);

            if (!request.RequestUri.AbsoluteUri.Equals("https://www.googleapis.com/oauth2/v2/userinfo"))
            {
                return response;
            }

            response.EnsureSuccessStatusCode();
            var text = await response.Content.ReadAsStringAsync();
            JObject user = JObject.Parse(text);
            JObject legacyFormat = new JObject();

            JToken token;
            if (user.TryGetValue("id", out token))
            {
                legacyFormat["id"] = token;
            }
            if (user.TryGetValue("name", out token))
            {
                legacyFormat["displayName"] = token;
            }
            JToken given, family;
            if (user.TryGetValue("given_name", out given) && user.TryGetValue("family_name", out family))
            {
                var name = new JObject();
                name["givenName"] = given;
                name["familyName"] = family;
                legacyFormat["name"] = name;
            }
            if (user.TryGetValue("link", out token))
            {
                legacyFormat["url"] = token;
            }
            if (user.TryGetValue("email", out token))
            {
                var email = new JObject();
                email["value"] = token;
                legacyFormat["emails"] = new JArray(email);
            }
            if (user.TryGetValue("picture", out token))
            {
                var image = new JObject();
                image["url"] = token;
                legacyFormat["image"] = image;
            }

            text = legacyFormat.ToString();
            response.Content = new StringContent(text);
            return response;
        }
    }
}

[Edit: Updated with a different endpoint]

We'll see about getting a real fix into 4.0.1.

[hempels]

I think someone should try to figure out what the differences are (if any) in the data returned by using their openid connect endpoint versus their Me API. They might be the same under the hood or they might not.

[Tratcher]

They're not, the workaround above accounts for the difference.

[hempels]

I guess my real point was that if we were using a Me API from G+ before, I don't understand why we'd switch to an Open ID Connect API instead of using their other Me API that's outside of G+. Assuming the only reason for making the change is that one was deprecated, taking on any additional risk by switching paradigms seems unnecessary. I'm not opposed to it, I just don't understand the motivation.

[fhtino]

For info: the two, not deprecated Google UserInfo APIs, return very similar json.
The remapping in GoogleOAuth2AuthenticatedContext class should solve the whole issue.

https://www.googleapis.com/userinfo/v2/me
{
  "id": "106...............784",
  "email": "foobar...@gmail.com",
  "verified_email": true,
  "name": "John Doe",
  "given_name": "John",
  "family_name": "Doe",
  "link": "https://plus.google.com/106...............784",
  "picture": "https://lh4.googleusercontent.com/-vGrMT7f_lSE/AAAAAAAAAAI/AAAAAAAAAAA/xxxxxxxxx/photo.jpg",
  "gender": "male",
  "locale": "en"
}

https://openidconnect.googleapis.com/v1/userinfo
{  
  "sub": "106...............784",
  "name": "John Doe",
  "given_name": "John",
  "family_name": "Doe",
  "profile": "https://plus.google.com/106...............784",
  "picture": "https://lh4.googleusercontent.com/-vGrMT7f_lSE/AAAAAAAAAAI/AAAAAAAAAAA/xxxxxxxxx/photo.jpg",
  "email": "foobar...@gmail.com",
  "email_verified": true,
  "gender": "male",
  "locale": "en"
}