Planning for customer identity and access management

Applies to: External tenants (learn more)

Microsoft Entra External ID adds customer identity and access management (CIAM) to your app on the Microsoft Entra platform, so you get consistent app integration, tenant management, and operations across workforce and customer scenarios.

This article is a decision-making guide for the six planning steps. Each section summarizes the key choices and links to the canonical how-tos and reference docs.

Jump to a step for details, or go straight to the How-to guides.

Step 1: Create an external tenant

Your external tenant is the resource where you register apps and manage customer identities, separate from your workforce tenant. When you create it, you choose its geographic location and domain name. If you currently use Azure AD B2C, your existing B2C tenants aren't affected; see Plan your migration from Azure AD B2C to External ID.

The directory contains both admin accounts and customer accounts. Customers usually self-register; you can also create local accounts. Customer accounts have a restricted default permission set and can't see other users, groups, or devices.

How to create an external tenant

• Create an external tenant in the Microsoft Entra admin center.
• Don't have a tenant yet? Start a free trial.
• Using VS Code? Use the Microsoft Entra External ID extension (learn more).

Step 2: Choose an authentication approach

Decide how to build the sign-in experience before you register your app. This choice drives the rest of your integration.

• Browser-delegated authentication — Microsoft hosts the sign-in page; your app redirects users to it. Broad platform support, system-browser SSO, lower maintenance.
• Native authentication — your app hosts the sign-in UI and calls MSAL or the native authentication API directly. Full UI control, more development and security responsibility.

How to choose an authentication approach

• Choose an authentication approach — feature comparison and trade-offs.
• Native authentication overview — detail if you're considering native.

Step 3: Register your application

Register your app in your external tenant to establish a trust relationship with Microsoft Entra ID. The settings you configure depend on the authentication approach you chose in Step 2:

After you register the app, update your code with the application (client) ID, tenant subdomain, and (if applicable) client secret.

How to register your application

• Find platform-specific guidance on the Samples by app type and language page.
• If your platform isn't listed, follow the general register an application quickstart.
• For native authentication app settings, see How to enable native authentication.

Step 4: Integrate a sign-in flow with your app

Create a sign-up and sign-in user flow that defines the sign-in methods, attributes to collect, and identity providers for your app. You create the user flow the same way for both authentication approaches; the difference is how your app drives it at runtime:

Plan your user flow

• Number of user flows. Each app uses one user flow. You can share one flow across apps or create up to 10 per tenant for differentiated experiences.
• Attributes to collect. Decide which built-in attributes you need and whether you need custom attributes.
• Terms and conditions consent. Use custom attributes to capture consent with links to your terms and privacy policies.
• Token claims. Add required attributes to the token if your app depends on them.
• Sign-in methods. Local accounts (email OTP, email + password) work with both approaches. Federated providers (Google, Facebook, Apple, another Microsoft Entra tenant, custom OIDC) require browser-delegated authentication.

How to integrate a user flow with your app

• Define custom attributes (if needed).
• Create the sign-up and sign-in user flow.
• Add your application to the user flow.
• Wire up your app code:
  • Browser-delegated: follow a sample or quickstart for your app type.
  • Native authentication: follow the native authentication overview and tutorials.

Step 5: Secure your sign-in

Every customer-facing app needs MFA and a baseline security review. Native authentication apps have extra work: because your app is the exposed sign-in surface, you front it with a web application firewall (WAF). Browser-delegated apps inherit Microsoft's platform-level protections on the hosted sign-in pages.

• Enable MFA. Available MFA methods.
• Review security and governance. Conditional Access, risk-based policies, auditing. See Security and governance.
• Add bot protection (native authentication only). Requires a custom URL domain. See Integrate third-party bot protection.
• Add account takeover (ATO) protection (native authentication only). Requires a custom URL domain. See Integrate third-party ATO protection.

Step 6: Customize your sign-in

Customize the sign-in look and feel and extend it with your own business logic. With native authentication, your app owns the UI, so the Microsoft Entra company-branding feature doesn't apply — manage visuals and localization in your app code.

• Customize branding (browser-delegated only). Apply your logo, colors, and language strings to the Microsoft-hosted sign-in pages. See Customize the sign-in look and feel.
• Use a custom URL domain. Replace the default ciamlogin.com host with your own domain. Also a prerequisite for native authentication bot/ATO protection in Step 5. See Custom URL domain.
• Add custom authentication extensions. Extend the flow with server-side logic. Token-issuance extensions work with both approaches; attribute-collection extensions are browser-delegated only. See Custom authentication extensions.

Next steps

• Start a free trial or create your external tenant.
• Find samples and guidance for integrating your app.
• Learn how to migrate users from your current identity provider.
• See also the Microsoft Entra External ID Developer Center for the latest developer content and resources.
• Microsoft Entra External ID deployment guide for security operations