Microsoft Entra External ID (B2C)

Microsoft Entra External ID, commonly referred to as Azure AD B2C, is a customer identity and access management (CIAM) solution that handles authentication and authorization for external users—such as customers, partners, or citizens—of your applications. It is built on the same platform as Microsoft Entra ID (formerly Azure AD) but is a separate tenant designed for consumer-scale scenarios. B2C supports multiple identity providers (IdPs), including social accounts (Google, Facebook, Microsoft, Apple), enterprise SAML/WS-Federation IdPs, and local accounts (email/password or phone/OTP).

B2C operates on the concept of user flows (built-in) and custom policies (Identity Experience Framework). When a user attempts to sign in to an application, the application initiates an OAuth 2.0 or OpenID Connect (OIDC) request to the B2C tenant's authorization endpoint. B2C then executes a policy (either a user flow or a custom policy) that defines the steps of authentication: collecting credentials, validating them, calling external IdPs, and issuing tokens.

Step-by-step mechanism: 1. The application redirects the user to B2C's authorization endpoint with query parameters including the policy name (e.g., p=B2C_1_signupsignin). 2. B2C loads the policy's orchestration steps. Each step can be a self-asserted page (e.g., collect email and password), a technical profile (e.g., validate against a claims provider), or a redirect to an external IdP. 3. The user interacts with the B2C-hosted pages. For local accounts, B2C validates credentials against its internal directory (which stores user objects with claims). For social IdPs, B2C redirects the user to the social provider, which returns an assertion (ID token) to B2C. 4. B2C processes the assertion, maps claims (e.g., socialIdpUserId to objectId), and may call additional technical profiles (e.g., to read user data from a REST API, write to a database, or check for fraud). 5. After all steps complete, B2C creates a token (ID token, access token, or refresh token) containing claims as defined in the policy's output claims. The token is signed with B2C's private key. 6. The application validates the token (signature, issuer, audience, expiration) and uses it to authorize access to resources.

Azure CLI commands (az rest with B2C Graph API):

# List B2C tenants
az rest --method get --uri "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.AzureActiveDirectory/b2cDirectories?api-version=2020-05-01-preview"

# Create a B2C tenant (preview)
az rest --method put --uri "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.AzureActiveDirectory/b2cDirectories/{tenantName}?api-version=2020-05-01-preview" --body '{"location": "United States", "properties": {"tenantId": "{tenantId}", "sku": {"name": "PremiumP1", "tier": "A0"}}}'

PowerShell (AzureAD module):

# Connect to B2C tenant
Connect-AzureAD -TenantId "yourtenant.onmicrosoft.com"

# Get user flows
Get-AzureADMSIdentityProvider

# Get custom policies (via Graph)
Get-AzureADPolicy

Verification of token: Use jwt.ms or a tool like jwt.io to decode token. Check signature using the keys from https://yourtenant.b2clogin.com/yourtenant.onmicrosoft.com/discovery/v2.0/keys?p=<policy-name>.

Enterprise Scenario 1: E-commerce Platform with Social Login

A retail company wants customers to sign in using their Google or Facebook accounts to reduce friction. They deploy B2C with user flows for sign-up/sign-in. They configure Google and Facebook as identity providers by registering apps in those platforms and providing client IDs and secrets to B2C. During sign-up, they collect the user's email and name from the social IdP. The application (a .NET Core web app) uses the OIDC middleware. In production, they face issues with token size when many custom claims are added; they optimize by limiting claims. They also configure session timeout to 8 hours for convenience. A common misconfiguration is not setting the correct redirect URI in the social IdP app registration, causing login failures. They use Azure Monitor to track sign-in failures and set up alerts for sudden spikes.

Enterprise Scenario 2: Multi-Tenant SaaS with Custom Policies

A SaaS provider needs to allow each enterprise customer to bring their own SAML IdP (e.g., Okta, ADFS). They use B2C custom policies to define a SAML technical profile for each customer. The policy includes claims transformation to map SAML attributes to B2C claims. They also integrate with a REST API to check if the user's tenant is active. At scale (millions of users), they notice performance issues due to excessive REST API calls; they implement caching with Azure Redis Cache. They also use Azure Front Door to distribute B2C traffic globally. Misconfiguration of XML in custom policies leads to runtime errors; they use the IEF extension for Visual Studio Code for validation.

Enterprise Scenario 3: Mobile App with Phone OTP

A ride-sharing app uses B2C for phone-based authentication (OTP). They configure a user flow with phone sign-up/sign-in. The user enters their phone number, receives an SMS with a one-time passcode, and enters it in the app. The app uses MSAL for Android/iOS. They set the OTP code length to 6 digits and expiration to 5 minutes. In production, they encounter issues with SMS delivery delays; they implement a fallback to voice call. They also configure B2C to block suspicious sign-ins using risk-based conditional access (premium P2). A common pitfall is not handling the case where the user's phone number changes; they allow profile editing via a separate user flow.

What Goes Wrong When Misconfigured: - Wrong tenant domain: Using login.microsoftonline.com instead of b2clogin.com causes CORS or token validation errors. - Missing policy parameter: The p query parameter must match the exact policy name (case-sensitive). - Incorrect redirect URI: Must be exactly as registered, including trailing slashes. HTTPS is required (except for localhost HTTP). - Token validation: If the API does not validate the issuer correctly, it may accept tokens from other B2C tenants. - Custom policy errors: XML syntax errors or missing dependencies cause B2C to return a generic error page.