Description
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.