HttpContext.User Claims Aren't Present? Mostly an FYI.

[taylorchasewhite]

I know from reading other comments etc. that you guys are a small group reading, addressing and responding to these comments. I created a StackOverflow question relating to issues I'm having in linking my Blazor WASM app to AzureAD here, which almost entirely derived from following this article (thanks for the detailed write up).

I plead some ignorance on the the details of AzureAD and Identity, but one issue I hit when moving from my local accounts Identity server to this AzureAD login flow, is that the HttpContext.User now seemed to be empty. I'm not sure why.

Anyways, I hope/expect to get this answered on my aforementioned StackOverflow post so feel free to close this without any action as you see fit, but I wanted to call this out on this page in the small chance that there is an actual issue and/or others are having a similar experience and the docs might be modified to avoid this confusion. If you have any immediate thoughts as to why I'd be seeing this, please let me know as well.

Thanks,
Taylor

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 3039ff79-ee86-20b1-0082-d3899a84c823
• Version Independent ID: af4a3a75-ae52-5f6d-2120-737bc2fefb07
• Content: Secure an ASP.NET Core Blazor WebAssembly hosted app with Azure Active Directory
• Content Source: aspnetcore/blazor/security/webassembly/hosted-with-azure-active-directory.md
• Product: aspnet-core
• Technology: aspnetcore-blazor
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

Hello @taylorchasewhite ...

the HttpContext.User now seemed to be empty

I can't explain that behavior. My test app's HttpContext in the controller populates the User normally, and I get the user's claims. Their claims are from the access token, which include the identifier name for the user.

The only thing I can recommend is what you've done ... reach out to devs on support channels. As you noted, we're too small here to troubleshoot individual dev app issues.

• Stack Overflow
• ASP.NET Core Slack
• ASP.NET Gitter

I am interested to find out in the end what the cause of the problem is with your app. If we can call out a gotcha in the topic, it can save other devs trouble down the road. Please post back to this issue after you've sorted it out.

[taylorchasewhite]

Weird, so I figured out what the issue was by going through my test app as well, though I am unsure how this was working previously.

In the client side Program.cs, adding the protocol/scheme api:// to the scope URI gave me all the data on the request. Without the api://, this was empty. I protect all the routes except those that use a "no auth" http client, which worries me that perhaps they are not protected as I thought (will look into this later). Anyways, for the sake of my issue, the scheme missing was definitely the issue.

            builder.Services.AddMsalAuthentication(options =>
            {
                builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication);
                options.ProviderOptions.DefaultAccessTokenScopes.Add("**api://**{SERVER API CLIENT ID OR CUSTOM VALUE}/{SCOPE NAME}");
            });

[guardrex]

Yes, that's been a pain point for devs. It's covered at ...

https://docs.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/hosted-with-azure-active-directory?view=aspnetcore-3.1#register-a-server-api-app

App ID URI (for example, https://contoso.onmicrosoft.com/41451fa7-82d9-4673-8fa5-69eff5a761fd, api://41451fa7-82d9-4673-8fa5-69eff5a761fd, or the custom value that you provided)

... and there's a NOTE here ...

https://docs.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/hosted-with-azure-active-directory?view=aspnetcore-3.1#access-token-scopes

If the Azure portal provides the scope URI for the app ...

... because different scope values work for different devs depending on Azure AD portal version (probably 😖). When Javier sent his instructions over for documenting this, he had the "api://" scheme on his default scope. It didn't work for me until I removed that scheme. Even to this day, my test app runs correctly without it. We never confirmed what difference was exactly. I suspect that the difference was between using what Azure AD UI used to call the "Preview App Registration" vs. the legacy "App Registration" blade. They've dropped the legacy blade since then. I think that was the difference because the screenshots of his Azure portal didn't match what I saw in my Azure portal. Currently ... since we're this close to .NET 5's release ... we'll run a bit longer here and see if we can reach .NET 5 with the current dual-instruction set (with and without "api://") in the topics. We think that when we move to Identity Platform v2.0 for .NET 5.0 that we'll be able to stabilize the scope on just one thing ... indeed ... with the "api://" scheme.

btw - Another delta is between AAD and AAD B2C. The scope for B2C is with the "http://" and tenant domain. I hope that it becomes another difference that we can drop, but that might need to remain in place for other B2C-specific reasons out of our control.