Windows authentication sample for Blazor Web

[markat1]

I understand that windows authentication is not something that's recommended, BUT this is for projects running local protected environment, where I have access to active directory.

I'm struggling to find best practice when it come to having both a server and client side. So a sample is deperately needed.

In .net 6 I managed windows authentication with the following, which made me able to run username and hasrole without any issues across the whole application (after great tip from @javiercn):

//_Host.cshtml
@page "/"
@namespace TestExample.Pages
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

@{
    Layout = "_Layout";

    var userconfig = new InitialApplicationState
    {
        UserName = HttpContext?.User?.Identity?.Name,
        HasRole = HttpContext?.User?.IsInRole("test")
    };
}

<component type="typeof(App)" param-InitialState="userconfig" render-mode="Server" />

But in .net 9 I don't have _host anymore and I also need to manage with the client part. (followed the document in here)

So I tried with cascading authentication state, but I'm not sure if that's best practice.
Basically added builder.Services.AddCascadingAuthenticationState(), which then made me able
to cascade authentication state down to client, so I was able to use

Hello, @(!string.IsNullOrEmpty(context.User.Identity?.Name) ? "Mark" : "Not authenticated")

Though I was unable to receive user claims even after adding the following on server side (program.cs):

        builder.Services.AddRazorComponents()
                        .AddInteractiveServerComponents()
                        .AddInteractiveWebAssemblyComponents()
                        .AddAuthenticationStateSerialization(options => options.SerializeAllClaims = true);

Strange enough client is able to understand specific roles if I use @Attribute [Authorize(Roles = "myrole")], but I'm unable to receive the list of claims if I try manually fetching claims via @context.user.Claims

 <AuthorizeView>
    <p>Hello, @context.User.Identity?.Name</p>
    <p>@context.User.Identity.IsAuthenticated</p>
    <p>is in role test1?: @context.User.IsInRole("test1")</p>   // returns false even though it's true)
    <p>is in role test2?: @context.User.IsInRole("test2")</p> // returns false even though it's true)

</AuthorizeView> 

any clue what's happening here Luke ? @guardrex

[guardrex]

Hello @markat1 ... One quick question on that approach tho. You say that you had trouble with @context.user.Claims; but AFAIK, the claims would be in the auth state. In Halters sample, he gets them this way ...

https://github.com/dotnet/blazor-samples/blob/main/9.0/BlazorWebAppEntra/BlazorWebAppEntra.Client/Pages/UserClaims.razor

Could you try that and see what happens? BTW - I assume in the client project that you also have builder.Services.AddAuthenticationStateDeserialization(); (you didn't mention it, but I assume you have that). If the preceding approach with the auth state doesn't work, let me know. I'll advise you what we'll do next to get you some help with this.

[markat1]

Hello @guardrex - thank you so much for your reply! I provided following sample, just to show how my solution is wired - https://github.com/markat1/WindowsAuthenticationExample

Great news is that I did manage to get out my claims, but only as group ids. Would like to have the names out of every role.

IsInRole inside WindowsAuthorize stills shows false, when they should have shown true.

odd enough is that @attribute [Authorize(Roles = "role1, role2")] does contraint the whole page for just these 2 roles - so why can't WindowsAuthorize not see "role1" and "role2", but @Attribute can ?

[guardrex]

Sure thing ... and I'll take a look at your sample app tomorrow morning.

Great news is that I did manage to get out my claims, but only as group ids.

🎉 ... Great! The group ids coming out doesn't surprise me. Entra has similar behavior for security groups and built-in Admin roles.

IsInRole inside WindowsAuthorize stills shows false

so why can't WindowsAuthorize not see "role1" and "role2"

Let me take a closer look at that tomorrow and get back to you.

[guardrex]

It looks like your sample is in a private repo.

[markat1]

@guardrex so sorry! Should be public now! https://github.com/markat1/WindowsAuthenticationExample

[markat1]

Also tried the following under Routes.razor, but doesn't seem to work either on server or client side, when I add @attribute [Authorize(Roles = "test")]

Maybe it's the way in .net 8-9?

<Router AppAssembly="typeof(Program).Assembly" AdditionalAssemblies="new[] { typeof(Client._Imports).Assembly }">
    <Found Context="routeData">
        <AuthorizeRouteView RouteData="routeData" DefaultLayout="typeof(Layout.MainLayout)">
            <Authorizing>
               Checking to see wether you have access - please wait.
            </Authorizing>
            <NotAuthorized>
                You don't have the right persission to visit this part of the site.
            </NotAuthorized>
        </AuthorizeRouteView>
    </Found>
</Router>

[guardrex]

I took a look. Interesting use case to take a look at because this is one of the very few times that I've chatted with a dev about using Windows Auth in a Blazor app IIRC.

The app looks fine in general when using cascaded authentication state (AddAuthenticationStateSerialization/AddAuthenticationStateDeserialization), except that the product unit has made it clear that you can't rely upon HttpContext/IHttpContextAccessor for interactive rendering (CSR in this case, InteractiveWebAssemblyRenderMode). However, it's good to see that you were able to get the authentication state provider to process roles correctly (@attribute [Authorize(Roles = "role1, role2")]) in a way that you might be able to proceed with. For HttpContext/IHttpContextAccessor/@context-based code, that's not a supported approach for interactive rendering (SSR or CSR). It would only be valid for static SSR, and they still warn devs off of it ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/components/?view=aspnetcore-9.0#ihttpcontextaccessorhttpcontext

I've decided that we need better visibility (and improved content), so I opened dotnet/AspNetCore.Docs#34587. I'm going to create a new (short) article for HttpContext/IHttpContextAccessor under the Render Modes article to surface the product unit's recommendations better. Right now, this very important content is a bit too buried. I'll see if I can add some recent remarks that Steve and Javier made in discussion to further flesh it out.

As for your app, HttpContext/IHttpContextAccessor just isn't well supported for interactive rendering. There are a few edge cases where it will work. Otherwise, it comes down to the fact that interactive Blazor runs over a circuit or serves and starts the app on the client and just doesn't have a request-response lifecycle where an HTTP context exists.

If you can proceed with your app without HttpContext/IHttpContextAccessor/@context-based code and can successfully continue to rely upon cascaded auth state from the server, then I think† that you can proceed.

Of course, you know that I'm covering myself with "†think" because security in these cases is tricky and I'd hate to see an app break 💥 or have security bugs 😈 in it. I'm not a security guru. I defer to the product unit experts on this subject for anything that they haven't worked with me to publish in the articles.

If you have questions for the product unit about Windows Auth and Blazor, you can open them on their repo ...

https://github.com/dotnet/aspnetcore/issues

If you do, Please add ...

cc: @guardrex https://github.com/dotnet/blazor-samples/issues/460

... to the bottom of your opening comment so that I can follow the discussion.

We can close this issue because there are no sample app changes to make and Dan isn't going to agree to hosting a Windows Auth Blazor sample. He would've already asked for such a sample if he wanted one here. I'll work from the main repo issue that I just opened and try to resolve that this morning. I'll ping u on that PR when it goes up within an hour to two.

[markat1]

really appreciate you taking a look at my sample project + reply. @guardrex

So as I mentioned I came from .net 6 (blazor server app) and is currently upgrading blazor to .net 9 - So if people that makes local blazor Web (server + client) apps to an local IIS - what is the recommendable way of authorizing on client side? any samples?

For me it's important that I can use AD, because then I don't have to have an extra database for users, that's already in the AD. That's the whole reason why I always goes back to use of windows authentication - calling microsoft graph would result in latency and why call external when it's internal project?

[guardrex]

Sure thing!

calling microsoft graph would result in latency and why call external when it's internal project?

I hear u on that. You're pointing out that the doc set (and perhaps the framework itself) are biased against what you're trying to do ... and that it isn't clear why because Windows OS, AD, and IIS are all profit-making products that could be more fully addressed by the documentation. I'll circle back around to this point below.

We only have the samples that the product unit built, which are for Entra and OIDC ... or based on Identity, which as you say you're not keen on using because it requires a separate dB. The list is at ...

https://github.com/dotnet/blazor-samples?tab=readme-ov-file#sample-app-article-links-latest-release

There are third-party/community-based samples otherwise. I can say that hosting on IIS with AD just hasn't been a priority for management outside of the existing Windows Auth article in the main doc set for a server-side Blazor app. Dan hasn't asked for or indicated that he would like to have an interactive Auto or CSR BWA-based sample for AD (or going back prior to BWA/8.0, he never asked for a Blazor Server sample app). In fairness tho, the general idea has been that Blazor Server apps are just like ASP.NET Core apps for the most part and get wired up for security in the same way as a typical RP/MVC app. The tricky part was just passing tokens (i.e., access tokens, refresh tokens) to components, and we had that fairly well covered in the Blazor security guidance. Now, the tricky part is that and dealing with HTTP context during interactive rendering. Our current passing tokens guidance is horrible at the moment, referring readers to community-discussed workarounds. That's due for updates for .NET 10 (November, 2025) with some new framework feature that will roll out in preview sometime this year.

I feel that if you can meet your app specification without relying on HttpContext/IHttpContextAccessor/@context going with the cascaded auth state provider (AddAuthenticationStateSerialization/AddAuthenticationStateDeserialization), then you're taking the right approach ... in general ... again, I'm not a security expert. I'm rather afraid 😨 to give devs firm advice with scenarios for which the product unit hasn't provided guidance on.

Let's do this here ... let's leave this issue open for a bit while I reach out to Dan offline to ask him if he would like me to knock up an AD-based BWA with Interactive Auto rendering (similar to your CSR app) for publication here. I'll email him now, and I think he'll give me an answer quickly that I can post back here. I'll also ask him if we should be referring devs to just our main doc set Windows Auth article and guidance on not using HttpContext, etc. in BWAs with interactive render modes. I'll post back what he tells me as soon as I hear back. I might then further publish his remarks in the Security > Overview article.

[guardrex]

Ok ... I just emailed him. I'll post what he says as soon as I hear back.

[markat1]

Thank you so much @guardrex ! really appreciate your effort in trying to help out!

One last question for now -Would you recommend Entry via microsoft graph on client side as alternative to windows authentication? if yes, any samples on that? or articles?

[guardrex]

I'm not familiar with using MS Graph for that scenario. WRT coverage for MS Graph and Blazor specifically, we only have the Blazor WebAssembly guidance because that's tricky for devs to work with given the MS Graph guidance produced and maintained by the MS Graph doc authors. For server-side scenarios, like Blazor Server and BWAs, we refer devs to the MS Graph doc set because server-side Blazor apps are set up and run on the server like any server-side ASP.NET Core app.

For any samples that they've put out, you'd need to access their doc set. We're very compartmentalized here. The MS Graph doc authors are an entirely different team ... and I even think they aren't the same folks who maintain the Azure doc set.

[markat1]

Okay @guardrex - let me know reply from Dan - when he replies back.

[guardrex]

I just discovered something that I forgot about. We have a section warning devs off of Windows Auth for at least Blazor WASM at ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/?view=aspnetcore-9.0#windows-authentication

I'll need to check on this with Javier and get back to you. It might apply to the client side of BWAs.

[guardrex]

Good news @markat1! Dan is agreeable to adding both an article and a sample app for this scenario. I'm currently waiting on Stephen Halter to answer a question tho about the client-side situation. We might end up only supporting Windows Auth for interactive SSR ... not CSR ... perhaps due to the content that I cross-linked in my last remark. With CSR, it might lead to security vulnerabilities. I'll let you know what Halter says when he responds in the offline convo. As for timing of placing such an article and sample, I'm not sure exactly when I'll reach it. I would hope to reach it within a few weeks, but that's if nothing else with a higher priority, such as .NET 10 work, comes up to push it back.