Decouple Blazor external authentication handling and user persistence

[danroth27]

Original request from @kevinchalet:

#40764 (comment)

One of the main points that could be improved is how things are currently layered: unlike ASP.NET Core's authentication stack that offers specialized authentication handlers (cookies, OIDC, etc.), things are tightly coupled in the Blazor WASM world. More specifically, it would be great if the user persistence part (using local or session storage) was independent from the components handling the external authentication dance (in my case, OIDC). Something modeled after ASP.NET Core's IAuthenticationHandler/IAuthenticationService abstractions would be excellent.

#40764 (comment)

As I mentioned in my previous messages, the blocking part is the fact the external authentication handling and the user persistence parts are tightly coupled in the current implementation: Blazor exposes an IRemoteAuthenticationService that you can implement to handle the OIDC dance (which is fine), but it can't work alone without also creating a subclass of AuthenticationStateProvider as the default implementation - RemoteAuthenticationProvider - is a simple wrapper around oidc-client-js.

The two things should be decoupled so that you can create IRemoteAuthenticationService integrations without also implementing the local/session storage parts (that should be ideally provided OOTB by Blazor WASM).

An ASP.NET Core sample using the OpenIddict client stack can be found here: https://github.com/openiddict/openiddict-core/blob/dev/sandbox/OpenIddict.Sandbox.AspNetCore.Client/Controllers/AuthenticationController.cs

As you can see in that sample, OpenIddict itself only handles the external authentication dance: the persistence part is handled by ASP.NET Core using the cookie middleware, which is not something we can (easily?) replicate with Blazor due to the tight coupling I mentioned.