B2C authentication with Dynamics 365 — Entra External ID and beyond

Dynamics 365 needs to authenticate two kinds of users: internal employees (Entra ID workforce identities) and external customers and partners (B2C-style identities). The patterns for the second case have evolved — Azure AD B2C, Power Pages's built-in identity providers, and now Microsoft Entra External ID. Knowing the options and the trade-offs is essential for any customer-facing deployment.

Internal vs external identity.

• Internal (workforce) — employees with Entra ID accounts. Single tenant, controlled provisioning.
• External (customer) — customers, partners, suppliers. Many millions potential. Self-registered. Different lifecycle from employees.

Putting customers in the workforce Entra ID tenant is a bad idea — different lifecycle, different scale, license implications.

Azure AD B2C (legacy). The historical Microsoft B2C identity solution:

• Separate tenant from workforce.
• Self-registration via custom policies.
• Social identity providers (Google, Facebook, Apple).
• Custom branding.
• MFA configurable.

Used widely; mature; supported. New deployments now have an alternative.

Microsoft Entra External ID. Rebranded and modernised replacement:

• Same conceptual model — external identity tenant.
• Integrated with modern Entra features.
• Improved developer experience.
• Same auth protocols (OAuth, OIDC).

For new B2C deployments, Entra External ID is the path. Existing Azure AD B2C continues to work but Microsoft's investment is shifting.

Power Pages identity providers. Power Pages portals can authenticate users via:

• Local accounts — username/password in Dataverse (small scale only).
• Microsoft accounts — personal Microsoft accounts.
• Entra ID — workforce accounts.
• Entra External ID / Azure AD B2C — purpose-built customer identity.
• Social providers — Google, Facebook, LinkedIn.
• SAML 2.0 — enterprise federation.
• OAuth 2.0 — generic.

For customer portals, the combination of Entra External ID + selected social providers is common.

The contact-record binding. Power Pages binds an authenticated user to a Dataverse contact record:

• First-time login → contact lookup by email or external ID → if found, bind; if not, create.
• Subsequent logins use the binding.
• The contact's web roles drive what the user can see and do.

This is the mechanism connecting authentication (who) with authorisation (what).

User registration flows.

• Self-registration — user signs up; account created with limited access; possibly admin approval for elevated access.
• Invitation-based — admin invites; user redeems invitation; account created with pre-configured role.
• Federation — user's enterprise IdP federates; user appears with prior trust.

Different flows suit different B2C scenarios — public portal vs partner portal vs supplier portal.

MFA for external users.

• Strongly recommended for any portal accessing sensitive data.
• Configurable per identity provider.
• Step-up MFA — required only for high-risk operations.

Single sign-on (SSO) for customers. If the same customer authenticates across multiple Microsoft-hosted properties:

• Single Entra External ID tenant.
• Customer signs in once, accessing all properties.
• Sign-out propagates.

Reduces friction; improves customer experience.

Custom user attributes. External identity tenants can store:

• Standard claims (email, name).
• Custom claims (loyalty number, tier, preferences).

Claims flow into the application as token claims at sign-in. Available for personalisation and authorisation.

Conditional access for external users.

• Risk-based — block sign-in from suspicious locations.
• Device-based — require managed devices for sensitive access.
• App-based — different rules per app.

Same Conditional Access framework as workforce, applied to external identities.

B2C with Dynamics 365 specifics.

• Customer self-service portal — Power Pages + Entra External ID.
• Partner portals — same pattern; partner-specific business logic.
• Supplier portals — for F&O vendor collaboration; Entra External ID for supplier sign-in.
• Marketing forms — anonymous-to-known conversion; identity captured on first form submission.

Pricing and licensing.

• Entra External ID priced per monthly active user (MAU).
• First N users free; pay-per-user beyond.
• Compared to AAD B2C: similar economics, modernized billing.

For high-volume consumer portals (millions of users), unit economics matter — model carefully.

Migration from Azure AD B2C to Entra External ID.

• New tenant creation.
• User migration — depending on volume, batch process.
• Application reconfiguration — update endpoints.
• Custom branding ported.
• Testing.

Microsoft provides tooling and guidance; migration is non-trivial but achievable.

Common pitfalls.

• Customers in workforce tenant. Wrong tenant; licence cost; security risk.
• Local accounts at scale. Username/password storage in Dataverse for thousands of customers; password management nightmare.
• No MFA. Customer accounts compromised; data exposure.
• Single failure point. Only one IdP supported; if it's down, all customers locked out.
• Identity-to-contact mismatch. Email-based binding fails when customer changes email; new contact created; history lost.
• Conditional access too strict. Legitimate customers blocked.

Operational guidance. For new customer-facing Dynamics 365 deployments:

• Use Entra External ID.
• Layer in social providers based on audience.
• Enable MFA at minimum for sensitive operations.
• Conditional Access policies appropriate for risk profile.
• Plan contact-record binding lifecycle carefully.

Strategic positioning. Customer identity is foundational for any external-facing Dynamics 365 deployment. The platform supports flexible patterns; choosing the right one depends on audience size, security needs, and integration complexity. Entra External ID is the strategic direction; for new projects, it's the default choice. The investment in clean identity architecture pays back continuously — every customer self-service interaction depends on it working reliably.