-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider re-designing the Blazor WASM authentication stack #40764
Comments
@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 |
Sadly, this led to an odd design:
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? 😃
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
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 |
(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. |
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? |
@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. |
I gave the MAUI flavor a try when creating the OpenIddict client MAUI integration prototype and it's really fun! (amusingly, when the first Blazor bits were released, I suggested that Blazor should be in its own
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 The two things should be decoupled so that you can create
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. A MAUI prototype with a sample targeting both Twitter and a local OIDC server (currently WinUI-only, unlikely to ship as part of OpenIddict 4.0 due to the low demand) can also be found here: https://github.com/kevinchalet/openiddict-core/tree/maui_winui_sample/sandbox/OpenIddict.Sandbox.Maui.Client The Blazor WASM prototype is not currently public as it's not fully working, but if you're interested in taking a look, let me know and I'll make it public 😃
That's fine: crypto support in 7.0 is still extremely lacking so I wasn't expecting anything concrete for 7.0 🤣 |
Thanks for contacting us. We're moving this issue to the |
My interest in this is the limitation to impersonate my tenants as host abpframework/abp#9997 |
Would be good to consider baking token generation back into ASP.NET Core, so that we're not reliant on third party packages / cloud solutions. See blog post for more details: |
I want to port my Blazor WASM app (that uses auth) to Blazor MAUI Hybrid. I wish there was a common abstraction. |
It is rather painful that returning a token from the identity server triggers a reload of Blazor WASM. There might be a path with the new Blazor United to perform the authentication server side and then transition to client side with the received token? |
@mkArtakMSFT The current implementation with iframes and silent signin based on oidc-client-js is causing some timeout issues with third-party IdPs. I've described the cause of this issue in this Stackoverflow question: Blazor WASM - Spending a long time initially in Authorizing component. I'll add my analysis results below. IMHO, the new solution should allow more freedom for cases like this, where you cannot influence IdP configuration like Source of issueThe issue is caused by a timeout in the underlying implementation of the authentication services. I traced down the source, but there's no easy solution to this issue. If you enable Debug tracing for your WASM client, you should see this log message in the console:
For me - using Keycloak (instead of Auth0), and Discord as IdP behind Keycloak - the Discord login cannot be framed in the hidden iframe:
Of course this policy can be modified to include What's happening
|
I'm wondering if there's not going to be a revamp of this like the author suggested, if at least there could be a refactor to base this implementation on a more modern and better maintained library like https://github.com/authts/oidc-client-ts, which would help reduce the hassle of migrating and revamping everything entirely, and will at least provide a more up-to-date library that fixes some of the problems with the old oidc-client.js that is no longer maintained since a couple years ago already (which I think it's a nasty thing for security purposes on a platform as young as Blazor). |
Some other issues I have with the current implementation that I'd love to see addressed in a future rework:
|
Another problem I just ran into:
|
Thanks for contacting us. We're moving this issue to the |
👋🏻
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?
The text was updated successfully, but these errors were encountered: