Microsoft Entra External ID Integration with Power Pages

Version: 2026-04-28
Author: Forrest Zhang

This guide explains how to configure Microsoft Entra External ID as the customer identity provider for a Power Pages site. It is written for admins/developers who need to repeat the setup in another environment.

This manual is based on the COA Demo integration path that was tested end to end. It includes not only the steps, but also why each step matters and what went wrong during troubleshooting.

1. What You Are Building

Power Pages will use Microsoft Entra External ID as the login provider.

The important point is that two systems are involved:

• Entra External ID owns user authentication.
• Power Pages/Dataverse owns the application user profile, which is represented by a Dataverse Contact.

Successful sign-in alone is not enough. The integration is only complete when Power Pages can connect the authenticated External ID user to the correct Dataverse Contact.

The final flow is:

1. User clicks sign in on Power Pages.
2. User is redirected to the hosted Entra External ID sign-in/sign-up page.
3. Entra External ID authenticates or registers the user.
4. Entra returns an ID token to Power Pages.
5. Power Pages maps the external identity to a Dataverse Contact.
6. If contact email matching is configured correctly, Power Pages reuses the existing Contact instead of creating a duplicate.

Why this matters: most configuration screens only prove that authentication works. Our main issue was after authentication, when Power Pages received the token and had to decide whether to link to an existing Contact or create a new one.

2. Important Concepts

Directory vs Tenant

In Azure/Entra screens, "directory" usually means the active tenant context.

• Workforce tenant: your internal company tenant, for employees and admins.
• External tenant: the CIAM/customer tenant, for public/customer app users.
• Directory ID: the tenant ID.
• Subscription: billing/resource container. A tenant can exist with or without Azure subscriptions visible in the current portal filter.

Example:

Type	Example	Purpose
Workforce tenant	hellox.ca	Admins, internal apps, Dataverse ownership
External tenant	helloxcoaexternal.onmicrosoft.com	Customer sign-in/sign-up identities
Power Pages site	coademo.powerappsportals.com	Application front end
Dataverse environment	COA	Stores Contacts and site settings

External ID User vs Dataverse Contact

These are different records.

Record	Stored in	Purpose
External ID user	Entra External ID tenant	Login account, password, social identity, MFA, token claims
Contact	Dataverse	Power Pages user profile and business/application data
External Identity	Dataverse adx_externalidentity	Link between an external login account and one Contact

Why this matters: when a person registers in External ID, Power Pages still needs to decide which Dataverse Contact to use. If the mapping is wrong, Power Pages creates a new Contact even when a Contact with the same email already exists.

3. Prerequisites

You need:

• Admin access to the Power Pages environment.
• Access to create or manage an Entra External ID tenant.
• Permission to manage app registrations in the External ID tenant.
• Permission to edit Power Pages authentication settings.
• Access to Power Pages Management / Portal Management app for site settings.

Recommended test data:

• One test Contact created manually in Dataverse.
• A fresh email address not already used by an External ID user or external identity record.

Why this matters: old test users and old adx_externalidentity records can make a new test look broken even after the configuration is fixed. For contact-mapping tests, start with exactly one Contact using the test email and no old external identity record for that same login.

4. Create or Select the External ID Tenant

If an external tenant already exists, use it. Otherwise:

1. Go to Microsoft Entra admin center.
2. Open Entra ID > Overview > Manage tenants.
3. Select Create.
4. Select External.
5. Enter:
   • Tenant name, for example Contoso Customer Identity.
   • Domain name, for example contosocustomers.
   • Country/region.
6. Link the tenant to an Azure subscription if required.
7. Wait for tenant creation to finish.
8. Switch directory to the new external tenant.

Why this matters: the External ID tenant is the customer identity boundary. Customer accounts, user flows, social providers, and the hosted sign-in pages live here. The workforce tenant is still used by admins, Dataverse, and Power Platform, but it should not be used as the customer login authority for this pattern.

Record these values:

External tenant display name: <external-tenant-name> External tenant ID: <tenant-guid> External tenant primary domain: <tenant-name>.onmicrosoft.com CIAM login domain: <tenant-name>.ciamlogin.com

Example:

External tenant ID: e05f6713-19d0-494b-b262-dde883003045 Primary domain: helloxcoaexternal.onmicrosoft.com CIAM login domain: helloxcoaexternal.ciamlogin.com

Use the ciamlogin.com domain for the Power Pages provider settings. Do not use login.microsoftonline.com/common, login.microsoftonline.com/organizations, or the workforce tenant ID for this External ID setup. Those endpoints can show a Microsoft login page, but they are not the correct customer tenant authority.

5. Create the Power Pages App Registration

In the External ID tenant:

1. Go to App registrations.
2. Select New registration.
3. Name it clearly, for example:

COA DEMO - Power Pages External ID

4. Use a single-tenant audience unless your design requires otherwise.
5. Add the Power Pages redirect URI as a Web redirect URI.

Redirect URI format:

https://<power-pages-domain>/signin-<provider-slug>

Example:

https://coademo.powerappsportals.com/signin-entraexternalid_1

6. Save the app registration.
7. Copy the Application (client) ID.

Why this matters: the app registration is the trust record between Power Pages and External ID. It defines which application is allowed to call the user flow and where External ID is allowed to send the user after authentication. If the redirect URI is wrong, login will fail after the user authenticates.

Record:

Application client ID: <client-id> Redirect URI: <redirect-uri>

6. Create the Sign-Up and Sign-In User Flow

In the External ID tenant:

1. Go to External Identities > User flows.
2. Select New user flow.
3. Choose Sign up and sign in.
4. Name it clearly, for example:

coa-demo-signup-signin

5. Choose the sign-in method:
   • Email with password, or
   • Email one-time passcode, or
   • Social providers like Google.

For this setup, Email with password worked.

6. Choose user attributes to collect.

Recommended built-in attributes:

Email Address Given Name Surname

7. Save the user flow.

Why this matters: the user flow controls the hosted sign-in and create-account experience. This is where you decide whether users sign in with email/password, email one-time passcode, Google, or another provider, and which attributes are collected during registration.

Note: built-in attributes such as Given Name and Surname can be collected and written to the External ID user. That does not automatically mean Power Pages will save those values to the Dataverse Contact. Power Pages needs claim mapping if you want token values to update Contact fields.

7. Associate the App with the User Flow

In the user flow:

1. Open the user flow.
2. Go to Applications.
3. Select Add application.
4. Add the Power Pages app registration.
5. Save.

Without this association, the app might authenticate but the user flow settings will not apply correctly.

Why this matters: creating a user flow does not automatically apply it to every application. The Power Pages app registration must be assigned to the user flow so External ID knows which sign-up/sign-in experience to run for that app.

8. Configure Token Claims

This part is critical. Power Pages needs an email claim in the ID token.

Power Pages processes these claims in this order:

email emails upn

If none of these is available, contact matching can fail and duplicate Contacts can be created.

Why this matters: Power Pages does not match Contacts by looking at the email field typed on the External ID registration page. It matches based on claims returned in the ID token. During COA Demo troubleshooting, authentication succeeded but Contact mapping failed because the expected email claim was not being returned in the right way.

Use the standard email claim for the first working setup. Avoid starting with preferred_username or custom claim names for contact matching. They can appear in tokens, but Power Pages contact mapping expects a predictable email claim.

Add the Standard Email Claim

Use Token configuration, not the Enterprise App Attributes & Claims claim editor, for the standard email claim.

In the External ID tenant:

1. Go to App registrations.
2. Open your Power Pages app registration.
3. Go to Token configuration.
4. Select Add optional claim.
5. Select token type ID.
6. Select:

email

7. Save.
8. If Azure prompts you to add Microsoft Graph permissions, accept the prompt.

Why this matters: email is a standard optional claim for the ID token. Adding it here tells External ID to include an email value in the token that Power Pages receives after sign-in.

Expected manifest result:

"optionalClaims": { "idToken": [ { "name": "email", "source": null, "essential": false, "additionalProperties": [] } ] }

Avoid This Mistake

Do not try to add a custom claim named email in Enterprise applications > Single sign-on > Attributes & Claims.

That screen may show:

This claim type is restricted

That is expected. The fix is to add email as an optional ID-token claim from the app registration's Token configuration.

Why this matters: the Enterprise App Attributes & Claims page is useful for some claim transformations, but email is a restricted standard claim name there. For this integration, the reliable path is App registrations > Token configuration > Add optional claim > ID > email.

Optional: Add Name Claims

After email matching works, you can add name claims if needed.

Use either:

• Built-in optional claims when available, or
• External ID Attributes & Claims mapping for custom token claims.

Suggested claim names:

given_name family_name

Suggested source attributes:

user.givenname user.surname

If using custom mapped claims from the Attributes & Claims editor, update the app manifest:

"api": { "acceptMappedClaims": true }, "isFallbackPublicClient": true

For the first working setup, keep it simple: add only the standard email optional claim first.

Do not add multiple competing email claim mappings until the base login and contact mapping works. Extra claims make troubleshooting harder because it becomes unclear which claim Power Pages actually used.

9. Configure Power Pages Identity Provider

In Power Pages:

1. Open the site in Power Pages Maker.
2. Go to Security > Identity providers.
3. Select New provider.
4. Choose:

Provider: Microsoft Entra External ID Protocol: OpenID Connect

5. Enter a clear provider name.

Example:

Sign in with Email

6. Complete the settings.

Use the External ID tenant endpoints, not the workforce tenant endpoints.

Authority:

https://<ciam-login-domain>/<external-tenant-id>

Example:

https://helloxcoaexternal.ciamlogin.com/e05f6713-19d0-494b-b262-dde883003045

Metadata address:

https://<ciam-login-domain>/<external-tenant-id>/v2.0/.well-known/openid-configuration

Example:

https://helloxcoaexternal.ciamlogin.com/e05f6713-19d0-494b-b262-dde883003045/v2.0/.well-known/openid-configuration

Client ID:

<application-client-id>

Redirect URI:

https://<power-pages-domain>/signin-<provider-slug>

Scope:

openid email profile

Why this matters: Power Pages is acting as an OpenID Connect client. It needs the external tenant authority, the app client ID, the redirect URI, and the scopes that request identity information. openid is required for OIDC. email and profile request useful identity claims.

10. Confirm the Provider Site Setting Prefix

Power Pages creates site settings with a provider key in the path.

Example:

Authentication/OpenIdConnect/EntraExternalID_1/Authority

In this example, the provider key is:

EntraExternalID_1

Your environment might use a different suffix. Always confirm the exact key by checking existing site settings.

Why this matters: Power Pages site settings are name-sensitive. A setting under EntraExternalID_1 does nothing for a provider whose actual key is EntraExternalID_2. Always copy the key from the generated provider settings instead of guessing.

11. Configure Contact Mapping

This is the most important Power Pages section if you need existing Dataverse Contacts to be reused.

These settings control what Power Pages does after External ID returns the authenticated user. External ID can prove who the user is, but Power Pages decides whether to create a new Contact or link the login to an existing Contact.

Open Power Pages Management / Portal Management app, then go to:

Website > Site Settings

Create or update the following site settings for the correct Website record.

Replace <provider-key> with the key from your site, for example EntraExternalID_1.

Allow Existing Contact Mapping by Email

Name: Authentication/OpenIdConnect/<provider-key>/AllowContactMappingWithEmail Value: True

Use True, not Yes.

Why this matters: this setting allows Power Pages to search for an existing Contact by email and attach the external login to that Contact. Without it, Power Pages is more likely to create a new Contact during first external sign-in.

Do Not Block Existing Email

Name: Authentication/UserManager/UserValidator/RequireUniqueEmail Value: false

Why false:

• If this is true, Power Pages can reject registration when the email already exists on a Contact.
• If this is false, Power Pages is allowed to continue and link the external identity when mapping is correctly configured.
• This does not automatically map Contacts by itself. It only removes the uniqueness block.

Practical meaning: RequireUniqueEmail = false does not mean "allow duplicate Contacts." It means "do not stop registration only because a Contact already has this email." The actual reuse of the existing Contact still depends on AllowContactMappingWithEmail and the correct email claim mapping.

Registration Claim Mapping

Name: Authentication/OpenIdConnect/<provider-key>/RegistrationClaimsMapping Value: emailaddress1=email

Why this matters: this tells Power Pages which token claim should be copied into the Contact email field during first registration. For contact reuse, it also makes the expected email field explicit.

Optional name mapping after confirmed working:

emailaddress1=email,firstname=given_name,lastname=family_name

Login Claim Mapping

Name: Authentication/OpenIdConnect/<provider-key>/LoginClaimsMapping Value: emailaddress1=email

Why this matters: login and registration are separate moments in the Power Pages authentication pipeline. Configure both so Power Pages can consistently read the email claim whether the user is registering for the first time or signing in later.

Optional name mapping after confirmed working:

emailaddress1=email,firstname=given_name,lastname=family_name

12. Restart Power Pages

Authentication and site setting changes can take time because Power Pages caches settings.

After changing site settings:

1. Open Power Platform admin center.
2. Select the environment.
3. Open the Power Pages site.
4. Restart the site.

Alternatively, clear the server-side portal cache if available.

Why this matters: Power Pages caches authentication and site settings. During troubleshooting, a correct setting may not take effect until the site is restarted or cache is cleared. Always restart after provider or site setting changes before testing again.

13. Test Existing Contact Mapping

Use a fresh test email every time unless you fully clean old test data.

Why this matters: once Power Pages creates an adx_externalidentity, that external login is linked to a specific Contact. If that link points to a duplicate Contact from an earlier failed test, fixing the settings will not automatically move the link to the correct Contact.

Prepare Dataverse

1. Open Dataverse Contacts.
2. Create exactly one Contact.
3. Set:

Primary Email = [email protected]

4. Make sure there are no duplicate Contacts with the same Primary Email.
5. Make sure there is no existing adx_externalidentity record for that email/user from a previous failed test.

Test Registration

1. Open the Power Pages site in a private/incognito browser.
2. Click Sign in.
3. Choose the Entra External ID provider.
4. Register with the same email as the existing Contact.
5. Complete the External ID sign-up.

Expected result:

• No new Contact is created.
• Existing Contact is reused.
• An adx_externalidentity record is created and linked to the existing Contact.
• The user can sign in normally.

This is the real success condition. Seeing the External ID user created in Azure is not enough. You must confirm the Dataverse Contact and adx_externalidentity records.

14. How to Identify Failure

Symptom: Duplicate Contact Created

Example:

Existing Contact: created manually by admin Duplicate Contact: created by # PowerPages Data Runtime PROD

Likely causes:

• email claim is missing from the ID token.
• Power Pages claim mapping still points to the wrong claim, such as preferred_username.
• AllowContactMappingWithEmail is missing or not True.
• RequireUniqueEmail is true.
• The site was not restarted after setting changes.
• There is more than one existing Contact with the same Primary Email.
• Testing reused an email that already has an external identity record attached to a duplicate Contact.

What we saw in COA Demo: External ID successfully created the user, but Power Pages created a second Contact with the same email. That proved the problem was not the External ID registration page. The problem was the token claim/contact mapping step inside Power Pages.

Symptom: "This claim type is restricted"

Cause:

• You tried to add email as a custom claim in the Enterprise App Attributes & Claims editor.

Fix:

• Add email in App registrations > Token configuration > Add optional claim > ID > email.

Symptom: Google or Social Provider Does Not Show

Check:

• Provider is configured under External Identities > All identity providers.
• Provider is selected in the user flow under Identity providers.
• User flow is associated with the application.
• Custom branding CSS is not hiding the federated credential box.
• Site/browser cache is cleared.

Symptom: Microsoft Login Picker Appears Automatically

This can be normal single sign-on behavior. The browser already has Microsoft/External ID sessions. Test in incognito or sign out from the External ID login domain.

This does not necessarily mean the provider is wrong. It often means the browser still has a valid session cookie for the External ID tenant or another Microsoft account.

15. Cleanup Failed Test Data

If a failed test created a duplicate Contact:

1. Find the duplicate Contact created by # PowerPages Data Runtime PROD.
2. Open related records.
3. Find related External Identity / adx_externalidentity.
4. Delete the external identity first if needed.
5. Delete the duplicate Contact.
6. Use a fresh email for the next test if possible.

Do not test repeatedly with the same email unless you understand which Contact the external identity is attached to.

Why this matters: deleting only the duplicate Contact may not be enough if an external identity record still points to it. Clean the external identity link first, then retest with clean data.

16. Optional: Add Google or Other Identity Providers

In the External ID tenant:

1. Go to External Identities > All identity providers.
2. Add Google, Facebook, SAML/WS-Fed, or another provider.
3. Configure client ID/secret or federation metadata.
4. Open the user flow.
5. Go to Identity providers.
6. Select the provider.
7. Save.
8. Test again from the hosted sign-in page.

Why this matters: adding Google under All identity providers only makes Google available to the tenant. It will not appear on the sign-in page until it is also selected in the specific user flow used by the Power Pages app.

Google Still Goes Through Entra External ID

When Google is configured as an identity provider, Power Pages still does not talk directly to Google. Entra External ID acts as the broker.

The flow is:

Power Pages -> Entra External ID hosted sign-in page -> Google authentication -> Entra External ID receives the Google result -> Entra External ID issues its own ID token to Power Pages -> Power Pages maps the user to a Dataverse Contact

Why this matters: Power Pages only trusts Entra External ID in this setup. Google is upstream of Entra External ID. Therefore, the final token sent from Entra External ID to Power Pages must still contain the correct email claim for Contact mapping.

For SAML providers such as BC Services Card, confirm:

• Federation metadata is valid.
• Required identifiers and certificates are configured.
• The provider is assigned to the user flow.
• The application is associated with the user flow.
• The token returned to Power Pages still contains an email claim that can map to contact.emailaddress1.

The same rule applies to every provider: Power Pages still needs a usable email claim in the final token. The upstream provider can be Google, SAML, or BC Services Card, but the token handed to Power Pages must still support Contact mapping.

17. Optional: Branding the Hosted Sign-In Pages

The Entra External ID sign-in/create-account pages are hosted by Microsoft, not Power Pages.

Power Pages header/footer changes do not automatically affect the hosted External ID pages.

Branding options are configured in the External ID tenant:

1. Go to Company branding.
2. Configure logo, background, colors, and layout.
3. For deeper layout/style customization, use the External ID branding/theme customization options where available.

Keep branding CSS conservative. Overly broad CSS can accidentally hide provider buttons like Google.

Why this matters: the External ID pages are not Power Pages pages. Styling them requires External ID branding/theme settings. Power Pages web templates, headers, and footers do not control the hosted Microsoft sign-in/create-account cards.

18. Recommended Final Configuration Checklist

External ID tenant:

• External tenant exists.
• App registration exists.
• Redirect URI is correct.
• User flow exists.
• App is associated with the user flow.
• Email sign-in method is enabled.
• Optional ID token claim email is configured.
• Social providers are assigned to the user flow if needed.

Power Pages:

• Entra External ID provider exists and is enabled.
• Authority uses ciamlogin.com and the external tenant ID.
• Metadata address uses ciamlogin.com and /v2.0/.well-known/openid-configuration.
• Scope is openid email profile.
• Contact mapping site setting is True.
• Require unique email is false.
• Registration/Login claims map emailaddress1=email.
• Site was restarted after changes.

Dataverse:

• Existing Contact has exactly one matching emailaddress1.
• No duplicate Contact exists for the test email.
• No old external identity is linked to a duplicate Contact.

19. COA Demo Example Values

Use these only as examples. Do not copy them to another environment.

Power Pages site: https://coademo.powerappsportals.com External tenant ID: e05f6713-19d0-494b-b262-dde883003045 External tenant primary domain: helloxcoaexternal.onmicrosoft.com CIAM login domain: helloxcoaexternal.ciamlogin.com Authority: https://helloxcoaexternal.ciamlogin.com/e05f6713-19d0-494b-b262-dde883003045 Metadata: https://helloxcoaexternal.ciamlogin.com/e05f6713-19d0-494b-b262-dde883003045/v2.0/.well-known/openid-configuration Provider key: EntraExternalID_1 Required Power Pages settings: Authentication/OpenIdConnect/EntraExternalID_1/AllowContactMappingWithEmail = True Authentication/UserManager/UserValidator/RequireUniqueEmail = false Authentication/OpenIdConnect/EntraExternalID_1/RegistrationClaimsMapping = emailaddress1=email Authentication/OpenIdConnect/EntraExternalID_1/LoginClaimsMapping = emailaddress1=email

20. What Actually Fixed COA Demo

The integration started working only after both sides were aligned:

1. External ID returned a standard email claim in the ID token.
2. Power Pages mapped emailaddress1=email during registration and login.
3. Power Pages allowed Contact mapping by email.
4. Power Pages did not block existing Contact emails with RequireUniqueEmail.
5. The site was restarted and old failed test data was cleaned or avoided.

The most important lesson: do not treat authentication success as integration success. Authentication success means External ID accepted the user. Integration success means Power Pages linked that authenticated user to the correct Dataverse Contact.

The final working model is:

External ID user email -> ID token email claim -> Power Pages Login/RegistrationClaimsMapping -> Dataverse Contact.emailaddress1 -> adx_externalidentity linked to that Contact

If any part of that chain is missing, duplicate Contacts or registration errors are likely.

21. References

• Microsoft: Set up Microsoft Entra External ID with Power Pages: https://learn.microsoft.com/en-us/power-pages/security/authentication/entra-external-id
• Microsoft: Create an external tenant: https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-create-external-tenant-portal
• Microsoft: Add user attributes to token claims: https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-add-attributes-to-token
• Microsoft: Configure optional claims: https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims
• Microsoft: Power Pages OpenID Connect FAQ: https://learn.microsoft.com/en-us/power-pages/security/authentication/openid-faqs
• Microsoft: Set up site authentication: https://learn.microsoft.com/en-us/power-pages/security/configure-portal-authentication

22. Security Note

Do not share admin passwords, client secrets, or test-user passwords in chat, email, screenshots, or documentation. If passwords or secrets were pasted during setup, rotate them after the environment is stable.