Decouple Blazor external authentication handling and user persistence
- Dominant language
- C#
- Stars
- 38.4k
- Forks
- 10.9k
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 281
Description
Original request from @kevinchalet:
https://github.com/dotnet/aspnetcore/issues/40764#issuecomment-1195532095
> 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.
https://github.com/dotnet/aspnetcore/issues/40764#issuecomment-1195532095
> 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.
Contributor guide
Research direction
Start by tracing IRemoteAuthenticationService, RemoteAuthenticationProvider, AuthenticationStateProvider, and the oidc-client-js integration in the Blazor WebAssembly authentication implementation. Compare the current local/session storage responsibilities with the requested ASP.NET Core-style separation; done means external authentication integrations can work independently while persistence remains available as a built-in provider.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, javascript
- Domain
- authentication
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100