Decide if we want to replace the Blazor dependency on oidc-client.js

[danroth27]

The oidc-client-js library library was archived, but we continue to ship it. This means we are currently responsible for supporting the library ourselves. We need to decide if we want to replace the library with a different implementation.

Some options:

• Switch to https://github.com/authts/oidc-client-ts
• Switch to a .NET implementation like https://www.nuget.org/packages/OpenIddict.Client
  • We are limited by lack of .NET crypto support when running in browsers
• Keep shipping oidc-client.js and continue to support it

Related discussion: #40764 (comment)

[wiktor-golonka]

@danroth27: In my opinion, switching to a .NET implementation would be best.

1. As part of Microsoft's security push this year, choosing a tested solution (assuming OpenIddict.Client) is the obvious choice.
2. Authentication doesn't need to be scary or difficult, but relying heavily on JS/TS‑based libraries behind the scenes adds unnecessary complexity.
3. Since the core logic resides in AuthenticationService.js and oidc‑client, we are forced into using obscure workarounds in both C# and JS if we want to implement scenarios beyond the basic ones.
4. It would be great to handle all advanced cases entirely in C#, which fits nicely with Blazor's spirit of C# development in the browser.

In the perfect scenario, we could use the WASM-ready OpenIddict.Client from @kevinchalet, since the non‑WASM‑ready client has already proven itself in battle, is trusted, and is very flexible. Speaking for myself, OpenIddict.Client would be my first choice because of the trust built behind the project. At the same time, I'm not sure how the limitations of the Cryptography library in browsers affect OpenIddict.Client at the moment.

Additionally, looking at the big picture, using a .NET solution from the community would strengthen the ecosystem and hopefully encourage more such great projects in .NET.

[kevinchalet]

In the perfect scenario, we could use the WASM-ready OpenIddict.Client from @kevinchalet, since the non‑WASM‑ready client has already proven itself in battle, is trusted, and is very flexible. Speaking for myself, OpenIddict.Client would be my first choice because of the trust built behind the project. At the same time, I'm not sure how the limitations of the Cryptography library in browsers affect OpenIddict.Client at the moment.

FYI, the OpenIddict client works fine with Blazor Hybrid on mobile/desktop platforms but it isn't usable in web browsers. If it's something we wanted to support, we'd need an OpenIddict.Client.BlazorWebAssembly companion package - or OpenIddict.Client.BrowserIntegration for something "generic" that doesn't depend on Blazor and directly uses JS interop instead - to deal with the browser-specific aspects, including:

• Storing the request forgery protection claim (rfp) OpenIddict generates to prevent session fixation attacks in the local/session storage or IndexedDB. AFAIK, Blazor still doesn't offer storage APIs to deal with that so it would require depending on an existing library (e.g https://github.com/Blazored/LocalStorage) or using JS interop.
• Redirecting the user agent to the authorization server when a login or logout demand is being processed (or opening a popup if a popup-based approach is preferred).
• Handling the login/logout callback request and validating the rfp value to ensure the reply is solicited (and prevent CSRF/session fixation attacks).

(note: I didn't include web or service workers in that list - tho' they have quite interesting advantages for increasing security in browser apps - as the recent drafts of the OAuth 2.0 for Browser-Based Apps RFC now treat this approach as a discouraged pattern).

At the same time, I'm not sure how the limitations of the Cryptography library in browsers affect OpenIddict.Client at the moment.

Last time I tried (i.e a few years ago 😄), both RSA and ECDSA - that are commonly used to sign identity tokens - were not supported in browser apps. Assuming https://learn.microsoft.com/en-us/dotnet/standard/security/cross-platform-cryptography is up-to-date, these asymmetric algorithms are still unsupported. It could probably be worked around by calling SubtleCrypto via JS interop, but it would need to be implemented in the MSFT IdentityModel library, since it's what OpenIddict uses to validate tokens.

That said, it's not a deal-breaker: the OIDC specification allows not checking the signature of identity tokens if (and only if) they were retrieved using a TLS-protected back channel, as the identity of the authorization server can be validated using the X.509 certificate authority. In practice, that would mean you'd only be able to use the authorization code flow and not the OIDC implicit or hybrid flows, which is a very reasonable compromise since the code flow is the recommended option anyway.

If it's really an approach the Blazor team is considering, I don't mind spending some time building a new prototype.