Consider re-designing the Blazor WASM authentication stack

👋🏻

The Blazor WASM OIDC authentication stack was built around the oidc-client-js library. Sadly, this library is no longer supported and the GitHub repository was archived last year.

As I suspect the ASP.NET team will consider opting for a different solution at some point, I guess it’s a good opportunity to discuss the design of the authentication stack and suggest potential improvements.

Last month, I unveiled the OpenIddict client, a new OAuth 2.0/OIDC client designed with extreme flexibility in mind (so it can be used with the worst non-standard server providers the world can offer 😄). As part of the effort, I’d love to provide native Blazor integration. I worked on a prototype based on the existing Blazor 6.0 authentication APIs and it’s promising, but I believe there’s place for improvement.

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.

Is it something that could be done as part of 7.0?

[kevinchalet]

Originally our auth system was implemented as a wrapper over JS libraries because they offered out of the box support for things like silent sign-in, etc. Given that the cookie changes have effectively killed most of those features, we are reconsidering our approach on this area.

Sadly, this led to an odd design: RemoteAuthenticationService aims at being an open/generic base implementation but it’s actually tied to oidc-client-js under the hood as AuthenticationService.ts is just a wrapper around it. Even things like storing or getting the current user identity are simple wrappers around oidc-client-js.

Replacing oidc-client.js is in our roadmap, that said, we are not looking at revamping the auth system with something as sophisticated as the auth system in ASP.NET Core.

I suggested that for one reason : ASP.NET Core’s authentication abstractions are battle-proven, extremely extensible and yet not insanely complex (they were inherited from Katana and got an overhaul as part of ASP.NET Core 2.0). So why would you reinvent the wheel? 😃

That said, we are considering what we do in this area, however in general we want to minimize as much as possible the number of primitives/complexity we ship in-box and enable people to integrate with our abstractions to tune auth to their needs.

Unlike ASP.NET Core - for which devs have written thousands of authentication handlers of all types - I personally haven’t seen many actual derived implementations of Microsoft.AspNetCore.Components.WebAssembly.Authentication, which makes me think the “enable people to integrate with our abstractions” part of the contract is not exactly fulfilled 😄

If you have concrete code snippets of what you are proposing I’m happy to move the conversation forward.

I don’t have specific snippets to share, but as I said in my OP, the main issue is how things are coupled. If at least the user persistence part was decoupled from the oidc-client-js, it would help a lot. Think of it as an equivalent of CookieAuthenticationHandler for Blazor (should I dare call that LocalStorageAuthenticationHandler or SessionStorageAuthenticationHandler?)

[kevinchalet]

(since the first post got already 5 👍🏻, I guess I’m not the only one interested in seeing improvements in this area 😃)