Introduction to Microsoft Entra External ID

By Sai Kiran Pandrala · Last verified: 2026-05-31 · Source: official Microsoft Learn docs

Microsoft Entra External ID is the rebrand-and-rebuild of B2C that started rolling out in 2025, and the migration story is where most of my conversations have been since January 2026. The rest of this guide is the path I run with my own hands when a customer pings me about introduction to microsoft entra external id. It takes me 20 to 60 minutes the first time I do it for a new tenant, and about 10 minutes from the second time onwards.

I have a small ritual before any B2C change. I open the activity log in one tab, the policy file in another, and a Postman collection in a third. Three tabs. That is the recipe. The first time I skipped opening the activity log was the same day I spent four hours chasing a ghost — turned out the rollout had succeeded immediately and my browser was sitting on a stale cache.

How I actually do it on a live tenant

Microsoft Entra External ID is the next-generation tenant SKU. The new external tenant gets created with:

az login
az rest --method POST --url "https://graph.microsoft.com/beta/tenantRelationships/managedTenants/managingEntities" \
  --body '{"displayName":"contoso-external","countryCode":"IN","tenantType":"AAD-External"}' \
  --headers "Content-Type=application/json"

Migration from classic B2C runs through Graph and a parallel-tenant approach — expect 3 to 6 weeks of work for a tenant with custom policies.

What I am doing here is the same thing you will do, the only difference is I have a few hundred reps and you might have two. Repetition does not change the steps; it changes what you notice while you do them.

Watch for one specific thing while you work: the correlation ID in the response headers of every B2C call. I copy it into a scratch note before I do anything else. If something breaks two steps later, I have the trail. Skipping that step costs me about an hour every time.

What changes the cost

The Microsoft Entra ID licence cost for a B2C tenant in 2026 ships in two tiers. Premium P1 lands at roughly USD 6 per monthly active user. about ₹500 per MAU at current exchange rates, and Premium P2 lands at USD 9 per MAU. Most of the consumer apps I ship sit on the free 50k MAU baseline and never hit a paid tier, because B2C bills only on identity transactions above that floor.

Time-wise: the configuration above takes me about 20 to 40 minutes on a tenant I have touched before. On a brand new tenant where I am also creating the app registrations, identity providers, and user flows from scratch, plan two to three hours. Document the path the first time. Forget the docs the fourth time.

Fast triage when it breaks (and it will)

I've seen this fail when the redirect URI in the app registration has a trailing slash and the SPA does not. I've seen it fail when the policy name in the authority string is lowercase and the actual policy ID in B2C is mixed-case. I've seen it fail because someone added a Conditional Access policy at the workforce-tenant level that does not even apply to B2C but the engineer was reading the wrong activity log.

The five-minute triage path I use:

1. Reproduce the error and capture the correlation ID. The error page in B2C surfaces a correlation ID at the bottom. Copy it. Without it, support gives you nothing.
2. Decode the token if you got one. A 401 from your API with a token in hand means audience / issuer / scope mismatch. jwt.ms works in a pinch; the PowerShell snippet above works in production.
3. Hit the well-known config URL directly. If curl https://yourtenant.b2clogin.com/yourtenant.onmicrosoft.com/B2C_1_susi/v2.0/.well-known/openid-configuration 404s, your policy ID is wrong. If it 200s but your client still fails, the client config is wrong.
4. Check the activity log filtered by correlation ID. az monitor activity-log list --correlation-id <id> --max-events 50. The signal is almost always in there.
5. Diff against your last known-good config. Even a one-character change in a redirect URI breaks the flow. git diff HEAD~1 -- src/authConfig.ts has saved me more times than the Microsoft Q&A forum has.

For the specific shape of error you are seeing, the error codes B2C surfaces are mostly self-explanatory once you read them slowly. AADB2C90006 is redirect URI mismatch. AADB2C90008 is the request is missing required parameters. AADB2C90027 is the request contains invalid query string parameters. AADB2C99002 is the user does not exist in the tenant. Knowing those four covers about 70% of what shows up.

How I verify before I close the ticket

Verification is the step everyone skips. I do not. Here is the checklist I work through:

• Happy path from a brand-new incognito window. Caching hides bugs. A fresh window does not.
• Happy path from a different device. I keep a Pixel 6a on my desk specifically for this. ₹26,000 well spent in 2024.
• Sign-up of a fresh user. Existing users have cached consent, cached tokens, cached everything. Fresh sign-up exercises the full path.
• Sign-in of an existing user. Different code path from sign-up. Both must work.
• Token introspection. Decode the token your client just received. Verify aud, iss, tfp, exp, and any custom claims.
• API call with the token. Hit one protected endpoint. Confirm 200, not 401.
• Sign-out and re-sign-in. Confirms the sign-out flow flushes the right tokens.
• Check the activity log 24 hours later. Some failures only show up under real load.

Plan a half-day for the verification on the first rollout, an hour on every subsequent rollout. Yes, an hour just to verify. Sounds like a lot until the first time you skip it and ship a sign-out bug to production.

Safety, rollback, and the conversation nobody wants to have

The rollback story for the change above is good: most B2C policy and app-registration changes are reversible because they live in policy JSON / XML or in the application object. The non-reversible ones are: deleting a user (gone after 30 days), promoting a tenant from B2C to External ID (one-way), and any custom policy that issued a token format your downstream services already cached.

• Export the app registration before you change it: az ad app show --id <app-id> > app.before.json.
• Export every user flow before you change it: portal → Identity Experience Framework → Custom policies → Download. Or via Graph: Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/identity/b2cUserFlows/B2C_1_susi" -OutputFilePath flow.before.json.
• Commit those exports to a private repo on the same change ticket. Reviewers see the diff. Auditors see the trail.
• Plan a maintenance window of 30 minutes for the change, even if the change itself is two clicks. Token cache invalidation can hold up real users for a few minutes after the policy edit.
• Have a working roll-forward path, not just a rollback. Rollback to broken state plus a hot-fix in 10 minutes beats rollback to broken state plus a guess in an hour.

The blast radius for the change above is one B2C policy or one app registration. Every app pointing at that policy or app ID is affected. az ad app list --query "[?contains(replyUrls, 'b2c_1_susi')]" gives me a starting point. Asking the team's Slack "who is pointing at policy B2C_1_susi?" finds the rest.

FAQ

Related fixes

Related guides worth a look while you sort this one out:

• Comparing External ID feature sets
• Microsoft Entra user resource type
• Publish your Azure Active Directory B2C app to the Microsoft Entra app gallery
• Authentication and authorization using the Microsoft identity platform
• Create an Apple ID application
• Microsoft Graph API interaction modes