SPA local development: Bearer authentication with Microsoft Entra External ID returns 403

(1) Share

Report

Posted on by CU11031005-0

Hi,

I’m working with a Power Pages SPA / code site and I’m trying to set up local development with Web API calls from localhost, following this documentation:

https://learn.microsoft.com/en-us/power-pages/configure/create-code-sites#set-up-local-development-by-enabling-web-api-calls-from-localhost-using-microsoft-entra-id-authentication

The setup works correctly when the authentication provider is the standard Microsoft Entra ID provider. I can call the Power Pages Web API from localhost using:

Authorization: Bearer <id_token>

However, after switching the site authentication provider to Microsoft Entra External ID, the same local Web API calls return:

403 Forbidden

The API works correctly after deploying the SPA to Power Pages, so table permissions, web roles, and the Web API configuration seem to be correct. The problem appears only when calling /_api from localhost with a bearer token.

My current site settings include an External ID provider with the provider key:

Authentication/OpenIdConnect/EntraExternalID_1/...

I tried the following bearer authentication configuration:

Authentication/BearerAuthentication/Enabled = true
Authentication/BearerAuthentication/Protocol = OpenIdConnect
Authentication/BearerAuthentication/Provider = EntraExternalID_1

I also tried other provider values, including:

Authentication/BearerAuthentication/Provider = AzureAD
Authentication/BearerAuthentication/Provider = EntraExternalID

but the result is still 403 Forbidden.

I also tested Authentication/BearerAuthentication/ValidIssuers.

Its claims look like this, with tenant-specific values masked:

{
  "aud": "<external-id-app-client-id>",
  "iss": "https://<external-tenant-id>.ciamlogin.com/<external-tenant-id>/",
  "name": "<user-display-name>",
  "tid": "<external-tenant-id>",
  "unique_name": "<user-external-email-address>",
  "upn": "<external-user-object-id>@<external-tenant-name>.onmicrosoft.com",
  "ver": "1.0",
  "email": "<user-external-email-address>",
  "given_name": "<user-first-name>",
  "family_name": "<user-last-name>"
}

The aud value matches the client ID configured for the Power Pages External ID provider.

The OIDC metadata endpoint configured for the provider returns an issuer like this:

{
  "issuer": "https://<tenant-id>.ciamlogin.com/<tenant-id>/v2.0"
}

I noticed that the issuer in the token does not include /v2.0, while the metadata issuer does. I also tried setting ValidIssuers to the exact iss value from the token, but the local Web API call still returns 403.

My questions are:

Is bearer authentication for local Power Pages SPA Web API calls supported with Microsoft Entra External ID, or is this local development flow supported only for the standard Microsoft Entra ID / AzureAD provider?
What should the correct value of Authentication/BearerAuthentication/Provider be for an External ID provider: EntraExternalID_1, AzureAD, EntraExternalID, or something else?
Should Authentication/BearerAuthentication/UseEntraV2Issuer be enabled for Microsoft Entra External ID in this scenario, even when the ID token has "ver": "1.0"?
How should ValidIssuers be configured when the token issuer and metadata issuer differ by /v2.0?
Is there any additional site setting required to allow localhost bearer-authenticated Web API calls when using Entra External ID?

Any guidance or a working configuration example for Power Pages SPA local development with Microsoft Entra External ID would be appreciated.

Thanks!

Categories:

Design & build

I have the same question (0)

All responses (2)

Answers (0)

Sort by

Suggested answer

Haque 2,944 on at

Like (1)

Report
Copy link

Link copied!
Hi @CU11031005-0,

Let's go through the question by question and see if you can have any luck.

Question-1: Is bearer authentication for local Power Pages SPA Web API calls supported with Microsoft Entra External ID, or is this local development flow supported only for the standard Microsoft Entra ID / AzureAD provider?

Bearer authentication for local Power Pages SPA Web API calls using Microsoft Entra External ID is generally more complex and less straightforward than with the standard Microsoft Entra ID (Azure AD) provider.

The standard Microsoft Entra ID (Azure AD) provider is fully supported + commonly used for local development with bearer tokens against Power Pages Web API.

Microsoft Entra External ID, being a CIAM (Customer Identity and Access Management ) solution with slightly different token issuer formats and validation requirements, can cause token validation challenges in local development scenarios.

Local development flows with Microsoft Entra External ID often require careful configuration of valid issuers, token audience, and app registrations including localhost redirect URIs.

Some token validation nuances (like issuer URL mismatches with or without /v2.0) can cause 403 Forbidden errors locally, even though the same setup works fine once deployed.

There is no explicit official statement that local bearer authentication with Microsoft Entra External ID is unsupported, but practical experience shows it is more fragile and requires extra configuration steps compared to the standard Azure AD provider.

Summary: local bearer authentication with Microsoft Entra External ID is possible but not as seamless or well-documented as with the standard Microsoft Entra ID provider. Most local development scenarios and samples use the standard provider for simplicity and reliability.

Question-2: What should the correct value of Authentication/BearerAuthentication/Provider be for an External ID provider: EntraExternalID_1, AzureAD, EntraExternalID, or something else?

The correct value for Authentication/BearerAuthentication/Provider in Power Pages when using Microsoft Entra External ID should exactly match the provider key you configured in your portal’s authentication settings. Typically, this is the name you gave when setting up the External ID provider in Power Pages, such as:

EntraExternalID_1 (or whatever custom provider key you assigned)

It should not be the generic values like AzureAD or just EntraExternalID unless those exactly match your configured provider key.

Summary: the provider value must be the exact string of the External ID provider key as registered in your portal’s Identity Providers configuration. This ensures the portal uses the correct OpenID Connect metadata and token validation settings for that provider.

Question-3: Should Authentication/BearerAuthentication/UseEntraV2Issuer be enabled for Microsoft Entra External ID in this scenario, even when the ID token has "ver": "1.0"?

The Authentication/BearerAuthentication/UseEntraV2Issuer setting in Power Pages is designed to control whether the portal expects tokens issued with the v2.0 endpoint issuer format (which includes the /v2.0 suffix in the issuer URL).

For Microsoft Entra External ID:

If your tokens have "ver": "1.0" and the issuer (iss) claim does not include /v2.0 (as in your case), then UseEntraV2Issuer should typically be set to false or left disabled. This tells the portal to accept tokens issued with the v1.0 style issuer URL.

Enabling UseEntraV2Issuer expects tokens with the /v2.0 issuer suffix, which does not match your token’s issuer claim and can cause validation failures.

Summary: For your scenario where the ID token version is 1.0 and the issuer URL lacks /v2.0, you should not enable Authentication/BearerAuthentication/UseEntraV2Issuer.

Question-4: How should ValidIssuers be configured when the token issuer and metadata issuer differ by /v2.0?

When the token issuer (iss) in your bearer token differs from the issuer URL in the OIDC metadata by the presence or absence of /v2.0, the recommended approach for configuring Authentication/BearerAuthentication/ValidIssuers in Power Pages is:

Include both issuer URLs in the ValidIssuers list to cover tokens issued with and without the /v2.0 suffix. For example:

https://<tenant-id>.ciamlogin.com/<tenant-id>/ https://<tenant-id>.ciamlogin.com/<tenant-id>/v2.0

This ensures that tokens from either issuer format are accepted during validation, avoiding 403 errors caused by issuer mismatches.

The list should be a semicolon-separated string of valid issuer URLs.

Make sure the issuer URLs exactly match the iss claim in the tokens you receive, including trailing slashes.

After updating ValidIssuers, restart your Power Pages site and clear caches to apply changes.

Summary: This dual inclusion is a practical workaround for the common discrepancy between token issuers and metadata issuers in Microsoft Entra External ID scenarios, especially for local development.

Question-5: Is there any additional site setting required to allow localhost bearer-authenticated Web API calls when using Entra External ID?

For local bearer-authenticated Web API calls using Microsoft Entra External ID in Power Pages, there are no widely documented additional site settings beyond the standard bearer authentication configuration. However, best practices and common requirements include:

Ensuring your External ID app registration includes localhost redirect URIs to allow token issuance for local development.

Configuring Authentication/BearerAuthentication/Provider to exactly match your External ID provider key.

Setting Authentication/BearerAuthentication/ValidIssuers to include the exact issuer URL(s) from tokens you receive locally (often both with and without /v2.0).

Using an access token (not an ID token) with the correct audience and scopes.

Restarting the Power Pages site after any authentication setting changes to clear caches.

Clearing browser cache or testing in incognito mode to avoid stale tokens or settings.

NOTE: No special or separate site setting explicitly enables localhost bearer authentication calls beyond these configurations.

Please let me know answers of your questions resolve the issue or not.

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!

Was this reply helpful? Yes No
Suggested answer

11manish 2,281 on at

Like (0)

Report
Copy link

Link copied!

Local Power Pages Web API calls using bearer tokens are currently designed to work with standard Microsoft Entra ID (Azure AD) and are not fully supported for

Microsoft Entra External ID.

The 403 error occurs due to differences in token issuer handling, validation expectations, and the use of ID tokens instead of access tokens.

Even with correct provider configuration and issuer settings, External ID tokens are not reliably accepted in the localhost development flow.

The recommended approach is to use standard Entra ID for local development or test against a deployed Power Pages environment, and ensure that access

tokens (not ID tokens) are used when attempting bearer authentication.

Was this reply helpful? Yes No