Consider re-designing the Blazor WASM authentication stack

[kevinchalet]

👋🏻

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 a 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 room 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?

[javiercn]

@kevinchalet thanks for contacting us.

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.

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.

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.

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

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[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 😃)

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[kevinchalet]

Given the number of 👍🏻 under my OP, I suspect the interest is strong. Is it on your radar, @javiercn? If so, can you share some details about your plan?

[javiercn]

@kevinchalet I am starting to look back at this area. We were in the middle of releasing Blazor Hybrid and this fell of my radar a bit.

For the time being, I am interested in understanding what concrete scenarios are not possible to implement with the current implementation to get a better view of the landscape as a first step.

I haven't looked at the client that you wrote, but I will take a look in the following weeks. I will also be interested in understanding what problems you faced when you tried to integrate with the current abstractions, maybe together we can identify what is missing. If you can provide concrete details on problems, maybe I can give some ideas.

Whatever we do here, this is going to be a .NET 8.0 feature/work.