Integration with .NET Identity

[fracampit]

Is your feature request related to a problem? Please describe.
There seem to be no built-in way to use the authentication (access_token) you get from an external login (Google) with .NET Identity with Google API.

The best I can find is essentially "don't use Identity, just use OpenIdConnect". Unfortunately, the system I am working on relies on other features that Identity offers, which forces me to having to stick with Identity.
Moreover, I have realised that the GoogleOpenIdConnect authentication returns an authorized user as long as you are logged in to Google on the browser, meaning that I cannot have an "Identity login" at the same time.
I have a set of existing Identity users, all with an external Google login. These users are then assigned roles by the application. Using GoogleOpenIdConnect would prevent me to keep using those roles as far as I understand.

Describe the solution you'd like
Be able to use IGoogleAuthProvider with Microsoft Identity and Google external login (.AddGoogle()), like when you use .AddGoogleOpenIdConnect.

Describe alternatives you've considered

• Manually intercept the access_token received during the .NET Identity external login and use that to initialize Google API services.
  This works, but persisting the token is a problem: implementing a solution that handles security, multi users, caching, refreshing etc would require too many resources

• Use .AddGoogleOpenIdConnect in conjunction with .AddGoogle.
  This doesn't work as the two login seem to conflict with each other - I am logged out of one when I call login with the other.

Additional Context
I am working on a .NET6 Website. This website will have multiple users and will allow them to upload videos to either their Drive account or their Youtube channel.
I can get this to work easily when running locally as I can use the 'Installed Applications' way of authenticating. I cannot get this to work when deployed on a server.

[fracampit]

I have also tried the following:

• Remove .AddGoogle and add .AddGoogleOpenIdConnect
• Set googleOptions.SignInScheme = IdentityConstants.ExternalScheme;

builder.Services.AddDefaultIdentity<ApplicationUser>(options =>
  {
      options.SignIn.RequireConfirmedAccount = true;
      options.Lockout.DefaultLockoutTimeSpan = TimeSpan.FromMinutes(30);
      options.User.RequireUniqueEmail = true;
      options.User.AllowedUserNameCharacters += "(";
      options.User.AllowedUserNameCharacters += ")";
      options.User.AllowedUserNameCharacters += " ";
  })
  .AddRoles<IdentityRole>()
  .AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddHttpContextAccessor();

builder.Services
  .AddAuthentication()
  .AddCookie()
  .AddGoogleOpenIdConnect(googleOptions =>
  {
      googleOptions.SignInScheme = IdentityConstants.ExternalScheme;
      googleOptions.ClientId = googleAuthCreds.ClientId;
      googleOptions.ClientSecret = googleAuthCreds.ClientSecret;
      googleOptions.Scope.Add(DriveService.ScopeConstants.DriveFile);
      googleOptions.Scope.Add(YouTubeService.ScopeConstants.YoutubeUpload);
      googleOptions.SaveTokens = true;
  });

With the above, I am able to signin to my Identity db using GoogleOpenIdConnect as an external login.
At this point, I would expect IGoogleAuthProvider to provide valid credentials when calling GetCredentialAsync(). However, I get Cannot get credential when not authenticated when trying that.

My theory is that setting googleOptions.SignInScheme = IdentityConstants.ExternalScheme; prevents OpenIdConnect from storing the fact that the user is authenticated, which then prevents IGoogleAuthProvider.GetCredentialAsync() from working.

Also tried to follow the Sample code, which has a method in the HomeController to retrieve the tokens:

var auth1 = httpContextAccessor.HttpContext?.AuthenticateAsync().Result;
var idToken = auth1?.Properties?.GetTokenValue(OpenIdConnectParameterNames.IdToken);
string idTokenValid, idTokenIssued, idTokenExpires;
try
{
    var payload = GoogleJsonWebSignature.ValidateAsync(idToken).Result;
    idTokenValid = "true";
    idTokenIssued = new DateTime(1970, 1, 1).AddSeconds(payload.IssuedAtTimeSeconds.Value).ToString();
    idTokenExpires = new DateTime(1970, 1, 1).AddSeconds(payload.ExpirationTimeSeconds.Value).ToString();
}
catch (Exception e)
{
    idTokenValid = $"false: {e.Message}";
    idTokenIssued = "invalid";
    idTokenExpires = "invalid";
}
var accessToken = auth1.Properties.GetTokenValue(OpenIdConnectParameterNames.AccessToken);
var refreshToken = auth1.Properties.GetTokenValue(OpenIdConnectParameterNames.RefreshToken);
var accessTokenExpiresAt = auth1.Properties.GetTokenValue("expires_at");

auth1?.Properties?.GetTokenValue(OpenIdConnectParameterNames.IdToken); returns null - (auth1?.Properties?.GetTokens() doesn't return any tokens`)

[amanda-tarafa]

I'm looking at this, I'll reply here as soon as I know more. I'm hoping I have some more info today.

[LindaLawton]

I have been faced with the exact same issues as @fracampit and have not been able to find a solution

I would like to chime in and state as that it would be awesome if we could store the refresh token returned as part of the user data in the database. This way the backend system could use the refresh token for automated tasks.

I have also been fighting with this exact same issue for months and have not been able to solve it.

[fracampit]

In case it helps, this is very close but uses .AddOpenIdConnect: https://stackoverflow.com/questions/66373175/oidc-together-with-asp-net-core-identity

[amanda-tarafa]

I've been looking at this most of today. I'm pretty sure I tested something very similar to what's described in the SO question and it didn't fully worked. I'll check my notes tomorrow and retest if necessary.
I'll come back here with any significant updates.

[amanda-tarafa]

I've made some advances in understanding what's happening, but I'm not fully there yet.
I have some other unrelated things I need to look at, I will come back to this next week and will update when I know more.

[amanda-tarafa]

Quick update: I didn't have time to look into this again this week, nor will I be able to do so next week.
I'll combe back to this on the first week of November.

[fracampit]

@amanda-tarafa Have you had a chance to get back on this?

[LindaLawton]

I was wondering the something last week. I'm really excited to see this working.

[amanda-tarafa]

No, I'm sorry, a couple higher priority issues have come my way, and this one has unfortunately dropped on the priority list.

For expectations: I would have though that this should work out of the box, and it doesn't. I understand why it doesn't but I haven't figured out how to work around it. I'm hoping it's a matter of configuration or slight code twaeking, but I might be wrong. I'll be able to dedicate one day to this issue, possibly next week, but not much more than that at the moment. If my hopes are met, and the fix is small, I'll bring it to conclusion, but else, we'll treat this as a low priority feature request and add it to our normal planning cycle etc. I'm conscious this is not what you wanted to hear, and I'm sorry about that. And hopefully, I can get it to work easily.

[LindaLawton]

Im a little confused as to how this could be a low priority feature request. Asp .net support is on the list of supported frameworks. So its defiantly not a feature request, if its something that's supported.

As has been shown in this thread Microsoft identity and the Google apis .net client authorization mechanisms area not compatible. For some reason this library has added identity into the mix when it should be purely authorization. Not user authencation.

IMO this is a major bug in this library that by authorizing a user. You also log them out of the application itself. I have had serval clients over they last two years who are using standard Microsoft identity and trying to add the use of Oauth2 to a Google api using this library. In both instances I had to drop this library completely and create it from scratch. Which basically means this library is not usable for Asp .Net and maybe that should be removed from supported frameworks and add it to the list of authorization frameworks we do not support. Unity, Xamarin ...

This library has always been an authorization library as it should be.

1. remove authencation aspect
2. stop clobbering the identity cookies.
3. return the refresh token to us so that we can create our own implementation of Idatastore or something to deal with token storage.

I still have not even figured out how to get the refresh token out of the cookie properly after authorization for storage..

[amanda-tarafa]

Asp .net support is on the list of supported frameworks.

Supporting ASP.NET Core does not imply supporting ASP.NET Identity, and we don't claim to or was this ever a requisite for Google.Apis.Auth.AspNetCore or Google.Apis.Auth.AspNetCore3.

In general, and across the many libraries, we don't support each API or specific framework defined by .NET or by ASP.NET, and definetely we don't intent to support them all. As an example of this, we only recently added some .NET DI support to the gRPC libraries in https://github.com/googleapis/google-cloud-dotnet.

For some reason this library has added identity into the mix when it should be purely authorization. Not user authencation.

Not sure what you mean here, surely there cannot be authorization without authentication. Say, even if some users were to use something else for authentication (like ASP.NET Identity), and we could hop into that for all cases, we wouldn't want to force all users to always need extra dependencies for authentication. The Google.Apis.Auth.AspNetCore packages are desgined to be used on their own.

IMO this is a major bug in this library that by authorizing a user. You also log them out of the application itself.

It's not a bug, it's the sympton of the suspected imcompatibility. But again, being compatible with ASP.NET Identity has never been a requisite of the Google.Apis.Auth.AspNetCore packages.

Which basically means this library is not usable for Asp .Net and maybe that should be removed from supported frameworks and add it to the list of authorization frameworks we do not support. Unity, Xamarin ...

No, the suspected incompatibility is between Google.Apis.Auth.AspNetCore packages and ASP.NET Identity, not with ASP.NET Core. Supporting ASP.NET Core does not imply supporting ASP.NET Identity.

1. remove authencation aspect

We can hardly do that, as we cannot perform authorization without authentication.

2. stop clobbering the identity cookies.

If by clobbering you mean overwriting or reusing, we are not. That's precisely why my initial inclination was that this should work out of the box. What's happening is that only one of the two cookies is ever saved, depending on who's configured to do what, and I still don't understand why or how to work around it.

3. return the refresh token to us so that we can create our own implementation of Idatastore or something to deal with token storage.
   I still have not even figured out how to get the refresh token out of the cookie properly after authorization for storage..

See here for how to obtain the refresh token every time it is issued: #1725 (comment)

All of the above said, the ideal outcome for us is that we can make the Google.Apis.Auth.AspNetCore packages fully supportive of ASP.NET Identity, while maintaining their capacity of being used on their own and without introducing any breaking changes. I still hope that can be achieved through configuration or even maybe some minor code tweaking. If that's the case, then we'll get this sorted before end of year (potentially sooner).

But if for making the packages compatible we need to make significant code changes, or even, if we need to produce entirely new packages (which is a posibility), then this feature request will go into our normal planning cycle and likely with a medium to low priority. I appreciate this is not what you want to hear, but it is the reality, and I'd prefer expectations to be reasonable, rather than have dissapointments later.

I'll come back to this thread with an update once I've had the chance to put some time into it, I'm planning that to be early next week.