ASP.NET Core Blazor WASM Standalone with Entra ID and ASP.NET Core API

Question

ASP.NET Core Blazor WASM Standalone with Entra ID and ASP.NET Core API

Ross 0

I am trying to follow the following articles.

The client will connect to ME-ID. I can connect to the API and retrieve data that is marked Allow Anonymous. I can retrieve User Claims, Access token and Access token claims.

My problem is that when I try to access a an Authorized end point I get a 403 response.I feel like I am missing something. Is there a working example anywhere that I can look at to compare?

Ross McLeod

Shubham Sharma 14,500 Reputation points Microsoft External Staff Moderator

2026-05-06T02:29:36.1466667+00:00
Hey Ross, it sounds like you’ve got the basics working—your Blazor WASM can talk to Entra ID, you’re pulling down user claims and anonymous API calls—but when you hit an authorized endpoint you get a 403. That almost always means either:

• Your client isn’t requesting the right scope,

• The API registration doesn’t expose that scope or isn’t configured to accept it, or

• Your Blazor app isn’t sending the token on the HTTP request.

Here’s a quick checklist and a pointer to a working sample you can compare against:

Expose and consume the right scope – In your API’s App Registration (“Expose an API”), make sure you’ve defined a scope (e.g. api://{API-Client-Id}/user_impersonation). – In your client App Registration, under “API permissions,” add that delegated scope and grant admin consent.

Configure your Blazor standalone app In Program.cs of your Blazor project you should have something like:
builder.Services.AddMsalAuthentication(options => { builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication); // This needs to match the scope you exposed on the API! options.ProviderOptions.DefaultAccessTokenScopes.Add("api://{API-Client-Id}/user_impersonation"); }); // Register an authorized HttpClient builder.Services.AddHttpClient("ServerAPI", client => client.BaseAddress = new Uri("https://your-api")) .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();
Then inject IHttpClientFactory or use the named client "ServerAPI" in your calls so the MSAL token is automatically added.

Secure your ASP.NET Core API In Startup.cs or Program.cs of your API project:
services .AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddMicrosoftIdentityWebApi(Configuration.GetSection("AzureAd")); services.AddAuthorization(); … app.UseAuthentication(); app.UseAuthorization();
And decorate your controller/actions with [Authorize].

Verify the token and scope If you decode the JWT (e.g. jwt.ms), you should see your custom scope (scp claim) in the token. If it’s missing or different, double-check your client’s DefaultAccessTokenScopes.

Compare with the official sample Microsoft maintains a end-to-end Blazor WASM standalone + Entra ID example on GitHub: https://github.com/dotnet/blazor-samples (look for the “standalone-with-microsoft-entra-id” sample in the latest folder). Clone that locally and compare Program.cs, appsettings.json, and the API project to your setup.

Hope that helps pinpoint what’s missing—once your client requests the exact scope your API exposes and you’ve wired up the BaseAddressAuthorizationMessageHandler, that 403 should turn into a 200.

Reference list

Tutorial: secure ASP.NET Core Web API with Microsoft Entra ID https://docs.azure.cn/en-us/entra/identity-platform/tutorial-web-api-dotnet-core-build-app

Secure a Blazor WebAssembly standalone app with Microsoft Entra ID https://learn.microsoft.com/aspnet/core/blazor/security/webassembly/standalone-with-microsoft-entra-id?view=aspnetcore-9.0

Blazor samples repo (standalone + Entra ID example) https://github.com/dotnet/blazor-samples

1 answer

Your answer

Answer 1

A 403 from an authorized API endpoint in this setup almost always comes from one of three configuration gaps:

The API’s scope isn’t being requested by the Blazor WebAssembly app.
The API isn’t configured to accept the audience/scope in the access token.
The app registration or redirect URI configuration is incomplete or mismatched.

Use the following checks based on the Blazor WebAssembly + Microsoft Entra ID guidance.

Confirm the API is exposed with a scope

In the API’s Microsoft Entra app registration, under Expose an API, ensure an App ID URI and at least one scope (for example, API.Access) are defined, similar to the hosted scenario where the App ID URI is api://{SERVER API APP CLIENT ID} and a scope like API.Access is added.
Record the App ID URI and scope name.

Ensure the Blazor WASM app requests the API scope The Blazor WebAssembly template does not automatically request an access token for a secure API.

In Program.cs (or equivalent), after AddMsalAuthentication, add the API scope to DefaultAccessTokenScopes:

builder.Services.AddMsalAuthentication(options =>
{
    builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication);

    // Request API access token as part of sign-in
    options.ProviderOptions.DefaultAccessTokenScopes.Add("api://{SERVER-API-CLIENT-ID}/API.Access");
});

Replace the scope string with the actual App ID URI and scope name from the API registration. This ensures the access token presented to the API contains the correct scp claim.

Verify Blazor WASM Entra configuration In wwwroot/appsettings.json, confirm the Entra settings match the client app registration:

{
  "AzureAd": {
    "Authority": "https://login.microsoftonline.com/{TENANT ID}",
    "ClientId": "{CLIENT ID}",
    "ValidateAuthority": true
  }
}

{TENANT ID} must be the Directory (tenant) ID.
{CLIENT ID} must be the Application (client) ID of the Blazor client app.

Confirm the SPA redirect URI and platform configuration In the client app registration:

Under Authentication → Platform configurations → Single-page application:
- Ensure https://localhost/authentication/login-callback is present as a redirect URI.
- Ensure Implicit grant → Access tokens and ID tokens are not selected, as implicit grant is not recommended for Blazor apps using MSAL v2.0 or later.

Validate the API’s token validation configuration On the ASP.NET Core API side, ensure the JWT bearer configuration matches the token being sent:

Authority should match the tenant (e.g., https://login.microsoftonline.com/{TENANT ID} or the appropriate instance/tenant).
Audience (or ValidAudience) should match the API’s App ID URI or client ID, depending on how the API is configured.

If the API expects a different audience or scope than what the Blazor app is requesting, the API will reject the token and return 403.

Use logs and network traces to pinpoint the issue If configuration appears correct:

Enable client-side authentication logging for Blazor WebAssembly as described in Client-side authentication logging in the Blazor logging guidance.
Use browser developer tools (Network tab) to inspect the call to the API:
- Confirm the Authorization: Bearer <token> header is present.
- Decode the access token and verify:
  - aud (audience) matches the API.
  - scp (scopes) includes the API scope (for example, API.Access).

If the scope or audience is missing or incorrect, adjust DefaultAccessTokenScopes in the Blazor app and/or the API’s Expose an API and JWT bearer configuration.

Common misconfigurations that lead to 403 From the documented common errors:

Missing or incorrect Authority, Tenant ID, Client ID, or Redirect URI in the client.
Incorrect request scopes (not adding the API scope to DefaultAccessTokenScopes).
Incorrect or missing server API permissions (API not exposed with a scope, or client not granted that scope).
Running the app at a different port than configured in redirect URIs for non-localhost addresses.

Correcting the API scope exposure and ensuring the Blazor WASM app requests that scope via DefaultAccessTokenScopes typically resolves 403 responses when anonymous endpoints work but authorized ones do not.

References:

Share via

ASP.NET Core Blazor WASM Standalone with Entra ID and ASP.NET Core API

1 answer

Your answer