Stop shipping new versions of the Microsoft.AspnetCore.Authentication.Google package

[halter73]

Google already ships its own official Google.Apis.Auth.AspNetCore3 NuGet package which has more features and is generally more up to date. As of a few months ago, dotnet/AspNetCore.Docs#33710 updated https://learn.microsoft.com/aspnet/core/security/authentication/social/google-logins to document using Google.Apis.Auth.AspNetCore3 rather than the Microsoft.AspnetCore.Authentication.Google NuGet package we ship.

Unlike the GoogleHandler we ship as part of Microsoft.AspNetCore.Authentication.Google which derives from OAuthHandler, the GoogleOpenIdConnectHandler handler implements the more modern OpenIdConnectHandler base type like Entra does in Microsoft.IdentityWeb. And in general, as with Entra and Microsoft.Identity.Web, we'd rather the teams behind the IdP provide their own integration packages built on top of OpenIdConnectHandler.

This also better sets it up refresh token support which is being tracked by #8175, because it probably makes sense to only add refresh token support to the OpenIdConnectHandler and not the OAuthHandler. While OIDC is not a prerequisite for refresh token support which is defined as part of the general OAuth 2 spec as part of RFC 6749, I think that OAuth implementations that do not include OIDC are less likely to support refresh tokens in general. @mkArtak @mikekistler

As you can see here in AddGoogleOpenIdConnect, here in GoogleOpenIdConnectHandler, and here in GetCredentialAsync the official Google package already handles token refresh, but it could probably be updated to leverage the work we're doing for #8175. At the very least we will want to make sure that our built-in token refresh doesn't interfere with what google is doing. I don't think it will because I think refresh will be opt-in and run during OnValidatePrincipal similar to how the ConfigureCookieOidc method in the BlazorWebAppOidc sample wires up the CookieOidcRefresher, and this would occur before calls to GetCredentialAsync which should always have fresh tokens.

It does make me wonder if we should have a design where we lazily refresh the token when acquiring it for a downstream call similar to Microsoft.Identity.Web's AcquireTokenAsync() or Google's GetCredentialAsync(), but that risks issues trying to set the cookie when response headers have already been sent like when handling SignalR Hub invocations over WebSockets in a Blazor Server app. Still, we could guard against that by checking HttpResponse.HasStarted and just not updating the cookie if it has. At least you'd still be able to get a fresh token for the ongoing request.

@jskeet @amanda-tarafa @chrisdunelm I see all of you in the commit history for the Google.Apis.Auth.AspNetCore3 package. Feel free to leave a comment if you have any opinions on us dropping the Microsoft.AspNetCore.Authentication.Google package or our plans to build in refresh token support to the OpenIdConnectHandler.

[halter73]

We could also stop shipping Microsoft.AspNetCore.Authentication.MicrosoftAccount which is probably best replaced by Microsoft.Identity.Web.

The two remaining provider-specific packages we maintain (outside of https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers which are maintained by external contributors) are Microsoft.AspNetCore.Authentication.Facebook and Microsoft.AspNetCore.Authentication.Twitter. It'd be nice to drop everything, but I'm not sure Facebook or Twitter have official AuthenticationHandlers that they ship. If so, we haven't documented it in https://learn.microsoft.com/aspnet/core/security/authentication/social/

[kevinchalet]

outside of https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers which are maintained by external contributors

It's worth noting that while these providers are still supported, our recommendation is to migrate to the OpenIddict-based providers: they are a lot cheaper to add and maintain (since they are source-generated) and offer many more features (including refresh tokens support). See https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers/tree/dev?tab=readme-ov-file#migrating-to-openiddict for more information.

While OIDC is not a prerequisite for refresh token support which is defined as part of the general OAuth 2 spec as part of RFC 6749, I think that OAuth implementations that do not include OIDC are less likely to support refresh tokens in general.

FWIW, that's not really true. Here's some concrete, actual numbers:

• OpenIddict supports 105 services (at the time of writing). You can find the complete list here or here (it's the file the source generator leverages to create all the options/builder APIs).
• 40 of them support both OIDC and either OAuth 2.0 authorization server metadata or OIDC discovery.
• The other providers (105 - 40 = 65) don't support OIDC or discovery and use a static configuration.
• Exactly 41 of these 65 OAuth 2.0-only providers support refresh tokens, which means ~63% of the OAuth 2.0-only providers do support token refreshing.
• Amusingly, even when they claim to support OIDC discovery, many of the OIDC providers don't correctly return the list of grant types they support, which requires fixing up the dynamic server configuration to list grant_type=refresh_token as a supported value (and we're not talking about obscure services but big players like DocuSign, Asana or Slack 🤣).

[jskeet]

Just to respond briefly at this point, @chrisdunelm is no longer at Google, but @amanda-tarafa and I are still working on .NET libraries and would welcome a chat about auth and more.

[chrisdunelm]

👋

[amanda-tarafa]

+1 to what @jskeet said. See googleapis/google-cloud-dotnet#13815 (comment) as well.

[SOHODeveloper]

@kevinchalet You say ,"our recommendation is to migrate to the OpenIddict-based providers". I see from the generation file, that there is now a Google provider being built. Are you recommending using OpenIddict Google provider vs the package that Google is supplying (google.apis.auth.aspnetcore3)?

I am talking about ASP.NET Core 9.x web application in which I am trying to provide authentication/authorization via Microsoft Account (via Entra external application), Google, Facebook and my own OIDC server (probably Duende).

[kevinchalet]

Are you recommending using OpenIddict Google provider vs the package that Google is supplying (google.apis.auth.aspnetcore3)?

I haven't tried that package so I can't make any recommendation (and it would be a bit biased anyway 😄). Give them a try and keep the one you like?