Practical patterns, flows, and architectural guidance for building customer identity and access management (CIAM) solutions with Microsoft Entra External ID.
Microsoft Entra External ID (formerly Azure AD B2C / External Identities) is Microsoft's CIAM platform for managing external users — customers, partners, and consumers — with flexible identity flows and deep customisation.
Manage sign-up, sign-in, and profile management for external consumers with support for social, local, and federated identities.
Built on OpenID Connect, OAuth 2.0, and SAML 2.0, compatible with any modern application stack.
Alternate patterns to support flows and mechanisms not covered by built-in User Flows.
See patternsCommon patterns used in Entra External ID implementations
Pre-built, configurable flows for common scenarios. Ideal for standard sign-up/sign-in requirements with minimal custom logic.
Hook into REST APIs at key points in user flows to validate data, enrich tokens, or enforce custom business logic.
Integrate external identity providers so users can authenticate with existing accounts without creating new credentials.
Layer additional verification factors into flows, or trigger step-up authentication at sensitive points in the user journey.
Control what claims appear in ID tokens and access tokens, and how downstream APIs verify and consume them.
Use the newer Custom Authentication Extensions to inject custom claims into tokens via a REST endpoint — without IEF XML.
Replace the default Entra pages with fully branded experiences using company branding or custom HTML templates.
Understanding the migration path and key differences between legacy Azure AD B2C and the new Entra External ID tenant model.
How the pieces fit together in a typical Entra External ID deployment
Request flow
Your app redirects the user to the Entra External ID authorization endpoint with the relevant user flow.
The user completes the configured flow — sign-up, sign-in, MFA, social IdP federation, etc.
Optionally, Entra calls your REST API to validate data, look up additional claims, or enforce business rules.
An ID token and/or access token is returned to your app, containing the configured claims.
Your app presents the access token to your protected API, which validates the JWT signature against Entra's JWKS endpoint.
Things to keep in mind when designing Entra External ID solutions
Start with User Flows unless you need a more development focused approach. Native Authentication APIs have a steeper learning curve but provide full control.
Always validate the iss (issuer), aud (audience), and exp claims
in JWTs. Use the JWKS endpoint from Entra's OpenID configuration document to verify signatures
rather than hardcoding public keys.
New projects should use the External ID tenant type (external tenant), not the legacy Azure AD B2C tenant. The External ID model is the strategic direction and aligns with the broader Entra platform — B2C tenants remain supported but won't receive new CIAM features.
API connectors and custom extensions add a synchronous call to the sign-in critical path. Keep your endpoint fast (target under 200ms) and implement retries + circuit breakers. Cold starts on Azure Functions can cause timeouts — use Premium plan or pre-warmed instances for production.
Approaches for scenarios not covered by built-in User Flows
When setting up a custom OIDC Identity Provider, there currently is a requirement for the token to contain an 'Email Address'.
But some providers do not supply this, so there is a pattern available that allows customization of the token supplied to EEID.
This utilizes a Function App that acts as an intermediary IdP to pass through requests and responses to EEID.
By default, Entra External ID requires users to sign in with an email address or a social identity. However, some applications require users to sign in with a username instead.
This pattern demonstrates how to enable sign in with username instead of email address.
We design and implement CIAM solutions using Entra External ID and custom identity flows.
Get in Touch