[Blazor] Improve authentification and usage of web apis

[MarvinKlein1508]

I haven't found any open issues regarding JWT and Blazor in general, so I might end up opening one myself.

This might be related to #38111. As well as to my previous issue #59433 which got closed in favor of #55307 (Which only covers WASM btw.)

Almost every web API uses JSON Web Tokens (JWT) to manage access for API endpoints. This often involves authentication being done on the web API itself, which then returns both an access and a refresh token to the client.

Since I have already authenticated the user on the web API, I want to use these tokens to authenticate my user in my Blazor app as well. But now the topic gets really complicated.

First off, the official docs themselves do not contain any information about JWT in Blazor at all. I've opened another issue regarding this in the docs repository: dotnet/AspNetCore.Docs#35225

OK, when there are no official docs from Microsoft, let's search the web! Surely someone was smart enough to figure out how this works! But it turns out that it is extremely difficult to find anything good related to this topic—especially when you only consider Blazor Server, not SSR or WebAssembly.

I've literally seen everything here:

• Custom cookie scripts to set cookies from interactive server mode
• Storing both the access token and refresh token in local storage and manually applying those values every time you want to call the API
• Ignoring refresh tokens altogether and simply providing an access token that expires in x months
• Saving the access token as a custom cookie and the refresh token in local storage (to fetch JWT from a custom AuthenticationStateProvider)
• Saving the JWT as a default claim in standard cookie authentication (often used with long-lived access tokens, since those cookies cannot be changed easily—especially with all the different render modes)
• Storing XML files on the server itself, which are read using the user ID and a custom AuthenticationStateProvider (Blazor Server and SSR)

I may not be the smartest person when it comes to authentication, but even I can see that there are major security penalties in each of these described "solutions."

Storing this information is only the first part of the story. It gets even more complex when you want to automatically refresh the access token and apply it to all requests from your Blazor app. Depending on your chosen hacky method from above, you either apply those from localStorage or cookies manually for each request. This also isn't 100% reliable, since you cannot access JSInterop in all render modes from Blazor.

Blazor is a really cool framework, but the authentication part is really hard to overcome—especially for newcomers. I strongly believe that Blazor could be so much more popular if these issues were addressed. Authentication has been driving me insane since .NET 3.1. Up to this date, I still haven’t figured out how to refresh the user's claims on the fly without logging out and back in.

[MarvinKlein1508]

@javiercn @danroth27 @guardrex @MackinnonBuck @SteveSandersonMS

[guardrex]

Thanks @MarvinKlein1508 ... I'll respond on your docs issue later today.

[guardrex]

@javiercn ... I chatted further with @MarvinKlein1508 on the docs issue, and he didn't realize a couple of things that would've helped ...

• "JWT" isn't a great search term in Blazor docs. We mention that in a couple of spots, but Blazor docs mostly only refer to "access token" in token-based scenario coverage.
• The Blazor articles rest on top of the main doc set's articles and don't seek to duplicate coverage in common areas. A BWA that adopts global Interactive Server rendering along with a web API secured with JWT Bearer is generally-speaking in overall setup, configuration, and behavior just an ASP.NET Core app with an identity provider/token server and web API with JWT Bearer auth, which is covered by the main doc set's article on JWT. The Blazor docs point this out in a few spots.

I'm going to leave the doc issue open as a reminder to look at how we're telling devs to use the main doc set's security articles. I plan to work on our passing tokens in BWAs coverage per Halter's remarks (on another issue) and work on overall content organization in the Blazor Security and Identity node (also another issue), and I'll probably see if anything can be done to help with @MarvinKlein1508's doc issue at the same time.

For our latest, greatest bits, I referred @MarvinKlein1508 to the recent Halter BWA sample apps, which partially address the inquiries here on the PU issue about token management.

[Krzywson]

Oh yes, the template with Blazor SSR and API Auth will be very useful. It would also be nice if you could select some information from Individual Accounts Users. Like I add a Permissions field and I could read it in a simple way or it would be stored somewhere.

[danroth27]

@claudiaregio

[MackinnonBuck]

cc @mkArtakMSFT about oauth token refresh: #8175

@MarvinKlein1508, we also have docs describing how to use OIDC with the BFF pattern: https://learn.microsoft.com/aspnet/core/blazor/security/blazor-web-app-with-oidc?view=aspnetcore-9.0&pivots=bff-pattern. Is this something you've seen?

There's also a way to share authentication cookies among ASP.NET Core web apps: https://learn.microsoft.com/aspnet/core/security/cookie-sharing?view=aspnetcore-9.0.

[MackinnonBuck]

Related: #59290

[guardrex]

There are significant updates coming soon on passing tokens for web API calls in Blazor Web Apps, including updates to our section on passing tokens, updates to the OIDC sample apps (both Server and Auto versions) that will call a separate web API project, and updates showing how to use the downstream API MS Identity Web package (Microsoft.Identity.Web.DownstreamApi) in the Entra BFF sample.

This work is in progress on dotnet/AspNetCore.Docs#35286 and should be finished and merged by the end of this week 🤞🍀.

[MarvinKlein1508]

@MackinnonBuck yes, @guardrex has shown me this guides. His current PR will add more demos for this regarding the other rendermodes. I really like this 🦖 guy.

My main issue roots down to that I have no idea what OIDC connect even means. I get that this is an auth standard which is widely used but I still need to take into account that I have a pre-existing database with simple usernames and hashed passwords which I cannot simply exchange for something brand new since the entire app relies on this table. I'm still wondering if the OIDC token is even a JWT token since I cannot verify it on jwt.io. I've tried creating my custom OIDC server based on openiddict. They provide many samples for different scenarios https://github.com/openiddict/openiddict-samples

The docs say you shouldn't create your own custom JWT tokens and you should use 0Auth 2.0 or Open ID Connect standards instead. In my case though it's only an internal business app which is only available on the local intranet.

Since all the docs only mention Microsoft Entra or stuff within Azure etc. I need to find a way to host this stuff on the local network since all stuff is hosted on-premise.

Are there any good 0Auth 2.0 or Open ID Connect frameworks for ASP.NET Core which you can recommend?

[MichaelHochriegl]

Are there any good 0Auth 2.0 or Open ID Connect frameworks for ASP.NET Core which you can recommend?

Not really a framework for ASP.NET Core, but have you considered using Keycloak? It's a OIDC server basically that you don't have to implement (auth is hard), so you spin up Keycloak as a container, set up the flows and import your users and can target this Keycloak instance with your apps.