Workforce identity secured, the series turns outward: the customers and partners who sign into your products. Building authentication yourself is a liability you operate forever; Entra External ID is Microsoft’s consumer and partner identity platform (the successor direction to Azure AD B2C, which stopped taking new customers), and it moves that liability to a platform whose job it is.

Two External Scenarios, Two Mechanisms

Partners collaborating in your tenant, accessing your Teams, SharePoint, and internal apps, is B2B collaboration: guest accounts in your workforce tenant, governed by cross tenant access settings that decide which external organizations you trust, whether their MFA claims are honored, and what your users can reach in the other direction. Customers signing into your product is the external tenant scenario: a separate tenant purpose built for consumer scale, holding customer accounts, sign up and sign in experiences, and the app registrations for your product. Keep the mental model clean, partners are guests in your house, customers get their own building, and half the confusing design sessions resolve themselves.

The Customer Experience Stack

An external tenant gives you self service sign up with email one time passcode or password, social providers (Google, Facebook, Apple) and any OIDC or SAML federation, branded pages with your logo, colors, and custom domains so the URL never breaks the product illusion, and custom attributes collected at registration. Two implementation choices matter early. First, browser delivered flows (standard OIDC redirects, the default, works everywhere, gets platform improvements free) versus native authentication, where your mobile app renders every screen itself and drives the API underneath, pixel perfect at the cost of owning the UX for every future credential type; choose native only when product design genuinely demands it. Second, MFA and risk: email OTP and SMS exist for consumers, but for anything valuable push toward passkeys, which are both more secure and less friction than passwords plus SMS, a rare free lunch.

Custom Extensions: Where Real Requirements Live

Every real deployment has the requirements the brochure omits: validate the invite code, check the customer against the CRM, block disposable email domains, enrich tokens with the loyalty tier from your database. Custom authentication extensions handle these: at defined events (attribute collection start and submit, token issuance start), Entra calls your REST API, an Azure Function behind the API Management patterns from this series, and your response modifies the flow, blocks with a friendly error, or injects claims into the token. That token enrichment pattern deserves emphasis, because pushing the tier lookup into token issuance means every downstream API reads it from claims instead of calling your database, which is both faster and one less coupling. Treat these extensions as production dependencies of your login path: the availability, retry, and monitoring discipline from the rest of this series applies, because when your extension is down, sign in is down.

Operationally: it is still Entra underneath, so the tooling transfers, sign in logs and Conditional Access (external tenants get their own policies, apply the risk based ones), Graph API for user management and migration, and the same alerting pipeline. Migration from B2C or a homegrown store is Graph driven bulk import with password hash migration where formats allow or forced reset journeys where they do not, and the honest advice is to migrate the users, not the custom policy artwork; External ID’s model is deliberately simpler than B2C custom policies, and most of that XML encoded logic maps to a custom extension and a cleaner flow.

Cheers
Osama