Aspnetcore.docs: Getting Authorization failed error when upgrading Blazor to 5.0 with Azure ADB2C

[mattruma]

Trying to update my Blazor App from .NET 3.1 to 5.0 following the guidance at https://docs.microsoft.com/en-us/aspnet/core/migration/31-to-50?view=aspnetcore-3.1&tabs=visual-studio.

Pre upgrade, my login with Azure AD B2C was working.

Post upgrade, my login is failing with the following message displaying in the console:

info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2]
      Authorization failed. These requirements were not met:
      DenyAnonymousAuthorizationRequirement: Requires an authenticated user.

The login screen displays, and I am able to enter to my credentials. The console message is displayed after I am returned to my site.

---

Document Details

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

• ID: b031caa0-c62b-37da-46c3-59043256cac2
• Version Independent ID: bdf98c9a-96f6-79fd-a650-5c0385d1a62b
• Content: Migrate from ASP.NET Core 3.1 to 5.0
• Content Source: aspnetcore/migration/31-to-50.md
• Product: aspnet-core
• Technology: aspnetcore-migration
• GitHub Login: @scottaddie
• Microsoft Alias: scaddie

[guardrex]

Hello @mattruma ... We've hit the topic twice thus far with updates, but I imagine that we're not quite there yet with this topic's coverage. The 5.0 approach moves from Identity v1.0 to v2.0 with the use of new MSAL packages and Azure config, particularly scopes. I suspect that this topic is missing a config instruction.

Until I get a chance to look at this topic (and I'll try later today, Sunday 11/8, to look), I recommend that you go to the 5.0 Preview Blazor WASM standalone or hosted topic (depending on your scenario), run down the sections of the doc looking for deltas between what the topic shows and your app/Azure config, and see if you can identify which configuration that we don't have in the migration topic (_yet_). Don't skip the opening section either on where it shows the use of the dotnet CLI command to create a new app because there are some deltas there that might apply and thus a hint might be evident. You'll also want to look there because that's where the Azure portal config is described. I'll do the same here later today if you don't find the problem and report back or if you just decide to wait until I get back to take a look and see if I can identify the possible MIA change to suggest to you.

If you don't spot an obvious delta, you could try to create a brand new app using the 5.0 Preview topic from scratch. Then, compare that app/solution to your app/solution looking for deltas. That's obviously going to take more time and effort, so you might want to do that last or give me a chance to look things over and get back to you later this evening.

Here are are the topic links to the 5.0 versions of those two scenarios ...

• https://docs.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/standalone-with-azure-active-directory-b2c?view=aspnetcore-5.0
• https://docs.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/hosted-with-azure-active-directory-b2c?view=aspnetcore-5.0

You'll know if you're on the 5.0 Preview version via the doc selector ...

Note to self: Given the number and scope of the deltas, we might need to backstop the migration coverage with 5.0 topic cross-links.

[guardrex]

@mattruma ... I took a look at the 5.0 updates to the regular docs against the migration topic and checked the product unit issues. They do have something going on over there with this error message, but idk if it's related. https://github.com/dotnet/aspnetcore/issues/23639

Try a few things just to make sure that the 😈 little gremlins 😈 that we know about aren't messing with us ...

• Double-check and confirm your Azure portal config with the 5.0 Preview version of the topic. I put the links in my earlier comment :point_up:.
• Kill 🔪 the bin and obj folders of all of the projects in the solution.
• Execute a dotnet nuget locals --clear all in a command shell to nuke your package caches. Sometimes, incompatible packages bring an app to its knees.

• Double-check that you're on the RC2 SDK (dotnet --info) compared to the latest RC2 SDK version at https://dotnet.microsoft.com/download/dotnet/5.0 and check the packages in the app are latest RC2 per nuget.org versions. The last time I worked with B2C (standalone), I had this ...

  <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="5.0.0-rc.2.20475.17" />
  <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="5.0.0-rc.2.20475.17" PrivateAssets="all" />
  <PackageReference Include="Microsoft.Authentication.WebAssembly.Msal" Version="5.0.0-rc.2.20475.17" />
  <PackageReference Include="System.Net.Http.Json" Version="5.0.0-rc.2.20475.5" />
  

• Restore/build/run and see if that clears it up.

WRT the migration guidance, I think in addition to a cross-link to the 5.0 topics that this should/could show the RC2 package set for each of the WASM security scenarios. We don't show versions in the regular docs because they change frequently, so we like to harden them against package version changes. Here tho, I think we can have the packages shown with RC2 or 5.0 versions ... I'll see what Scott and Rick are doing with the doc and follow their lead.

Before I do anything on Monday tho ... try those steps :point_up: and see what happens. We might need to get you to the product unit for further assistance. It is possible that you've hit a real framework-app problem that they'd like to know about. If you do get it running, leave this issue open. I would like to make a migration topic update, and this issue will close automatically when the PR merges.

[mattruma]

Thanks @guardrex for the quick and detailed response!

I did try all the steps you recommended, think I hit them all, double checked to make sure as I have missed steps in the pass, but looks good.

Verified correct .NET Versions as well.

Still getting the same error.

By the way, love that options.ProviderOptions.LoginMode = "redirect"; is an option now!

[guardrex]

Sure thing ... happy to help and sorry that it hasn't been resolved yet. I'm sure it will be figured out soon. If we need some additional docs work, we'll make that happen.

I'm not seeing anything obvious in the migration guidance other than the items that I listed here for work. We already have the SPA platform config Azure portal config and the scopes (openid and offline_access) called out.

You could try just one more thing if you haven't already done so. Try adding the https://graph.microsoft.com/User.Read scope to the app's default access token scopes (same spot as you're adding openid and offline_access). It shouldn't be necessary for a base case auth where the client-side app doesn't really access the user's profile data via Graph, but it's worth a quick check. Some apps that do use user profile data need that scope. It's worth a quick check. btw -- Be sure in all of these cases that you use a _new in-private/incognito browser_ for every single test of app or portal change. Lingering cookies can break an app. If you didn't already see it, the Troubleshoot section of these topics explains it all out. Anyway ... if adding that User.Read scope doesn't work, open a new issue for the product unit at ...

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

... _cross-reference_ that engineering issue ...

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

... that reported the same error language, but don't note anything on that one ... they'll indicate on your issue if it's a duplicate or related to that one. Just mention it in passing that the error message is the same. You might be hitting the same cause. If not tho, they'll want to work on your report separately from that one.

You can cross-link this issue on your engineering issue. Please add a cc: @guardrex to the bottom of your opening comment over there.

As usual over there, give them as much relevant info as possible: versions (SDK/framework, which is the output of dotnet --info). You might want to show your Program.cs where the scopes are being requested (just knock out any sensitive info). Maybe show appsettings.json ... again ... replace the sensitive bits (e.g., {MY COMPANY}.onmicrosoft.com). They might want a screenshot of your Azure portal config, blocking out the sensitive bits from the image(s). Worst case (time-wise) is that they will want to see a repro project on GH that they can look through to inspect the app/solution. You can put that up in advance or just be ready for them to ask for that.

Leave this docs issue open for work whether or not you get it running.

[mattruma]

Thanks again @guardrex! I want to make sure it is not something specific to my application, third party libraries, API, or something else, so going to do the following:

• [x] Create a new B2C tenant
• [x] Create a .NET 5.0 Blazor WASM, BlazorApp1, with Azure AD B2C authentication - just to make sure it works, for my own peace of mind 😃
• [x] Create a .NET 3.1 Blazor WASM, BlazorApp2, with Azure AD B2C authentication
• [x] Upgrade the 3.1 Blazor WASM to 5.0
• [ ] Update settings for the 3.1 Blazor WASM to 5.0 example to point to my original AD B2C instance

[guardrex]

Good idea. I ❤️ it because you may find something that I (we, with engineering guidance to me for docs) missed when performing 5.0 Preview updates to the docs. I might have time to walk it one more time myself prior to 5.0 GA. I'll try ... I'm 🏃😅 right now ... and 5.0 GA is really, _really_ soon ... but I'll try.

[mattruma]

K ... so it looks like it might be something in my App Registration in AD B2C, works with 3.1, but not in 5.0, trying to figure out exactly what it is.

[mattruma]

Hi @guardrex, think I figured out the issue.

I created another app registration in my Azure AD B2C tenant, and thing worked perfectly.

So I compared the manifests of the new app registration and the old app registration and other than differences in id and appId there was a difference in the value I had for allowPublicClient.

In my new app registration it was set to null in my old app registration it was set to false.

When I tested this in Fire Fox, in an effort to get some helpful error, I received the following:

https://localhost:5001/authentication/login-callback#error=unauthorized_client&error_description=AADB2C90058%3a+The+provided+application+is+not+configured+to+allow+public+clients.

When I set the value to null or true in my new app registration, I was able to authenticate correctly.

Which turned out to be the issue, seem .NET Core 3.1 version of the library either ignore this error or pass along some meta data that doesn't trigger this error.

Any way, got it to working, not sure though if it is really a Blazor issue.

[guardrex]

@mattruma ... That's both good news :tada: and very interesting. I just confirmed the behavior that you described, including how for a 3.1 app it doesn't seem to matter.

It could be a strange point-in-time problem for app registrations that they fixed ... or ... _OR_ ... 👽 ... Yes, they are among us! :smile:

Let's do this ... I'll add an entry to the Troubleshoot sections of the WASM topics for >=5.0 that says if the dev receives a ...

DenyAnonymousAuthorizationRequirement: Requires an authenticated user.

... or on login callback error of "unauthorized_client" with a description of "AADB2C90058: The provided application is not configured to allow public clients." that allowPublicClient in the manifest should examined to confirm that it's a null value.

I'll also add language to the Migration topic to cover it there just in case. My app registrations, both during 3.1 and 5.0, have defaulted to null. However, it would be quick to head off problems by mentioning it briefly just in case any readers, such as yourself, had some kind of app registration experience that didn't set it to null for some reason in 3.1 days when they set their app up.

I'll also make the other updates that I mentioned earlier. I should be able to knock this out on Tuesday morning. I'll ping you on the PR. Leave this issue open, as it will close automatically when the PR merges.

Thanks for your report and help in sorting it out.