What is Azure Active Directory B2C?

What is Azure AD B2C?

Azure Active Directory B2C is Microsoft's managed identity service for customer-facing apps. You point your web or mobile app at it, and it handles the sign-up and sign-in screens, the federation with social and enterprise identity providers, the password rules, the MFA prompt, and the tokens your app ultimately receives.

It speaks the protocols your app stack already knows - OpenID Connect, OAuth 2.0, and SAML - so integrating with it looks like integrating with any other identity provider. The difference is what's behind the contract: the user directory, the hosted UI, the threat protection, and the scale all belong to Microsoft.

Azure Active Directory B2C provides business-to-customer identity as a service.- Microsoft Learn

It is built on the same underlying technology as Microsoft Entra ID (formerly Azure AD), but it is a separate service aimed at a different audience. Entra ID is for your employees and partners. B2C is for the people who buy from you, sign up for your product, or use your public app - millions of consumer accounts that you do not want sitting in the same directory as your staff.

The problem it solves

Every customer-facing app needs the same pile of identity machinery: sign-up forms, password reset, email verification, "sign in with Google" buttons, MFA, account lockout after too many bad attempts, audit logs, a user database that scales to millions of rows. None of it is the product you are building. All of it is hard to get right, and very visible when you get it wrong.

You have three options. You can build it - and then run it, patch it, and answer security questionnaires about it for the rest of the app's life. You can buy it from a third-party CIAM vendor and pay per monthly active user. Or you can rent it from your cloud - which is what Azure AD B2C is.

The pitch is straightforward. You hand B2C the look and feel of your brand and the list of identity providers you want to allow. It gives you back a standards-compliant OIDC endpoint your app calls. Your app never sees a password.

The B2C tenant

The unit of isolation in Azure AD B2C is the tenant. A tenant is a directory of users plus the configuration that surrounds them: the registered applications, the identity providers, the user flows, the branded pages, the keys for signing tokens. Each tenant is its own world; tenants do not share users with each other or with the Microsoft Entra tenant where your subscription lives.

That separation is the point. Your employees in Entra ID and your customers in B2C are governed by different rules - different password policies, different MFA expectations, different attributes on the user object, different data residency requirements - and they should not be in the same directory by accident.

Inside a tenant, the resources you spend most of your time on are:

• App registrations - one per application or API that uses B2C, holding the client ID, redirect URIs, and the scopes the app can request.
• Identity providers - the local account provider plus any federated providers you turn on (Google, Microsoft, Facebook, X, generic OIDC, SAML).
• User flows - the built-in journeys for sign-up, sign-in, password reset, profile editing.
• Custom policies - escape hatch for journeys the user flows cannot express.
• Branding and page layouts - the HTML, CSS, and JavaScript that customize what users see.

Sign-in options

B2C supports three kinds of identity from day one, and a single consumer account can carry more than one of them at the same time.

You decide which buttons appear on the sign-in page and in what order. From the app's point of view, none of this matters: it asks B2C for a token, and a token comes back. Whether the user typed a password, tapped "Sign in with Google," or went through their employer's SAML IdP is hidden behind the same OIDC contract.

User flows and custom policies

The sequence of screens a user actually sees - "enter email, verify code, set password, accept terms, prompt for MFA, return to app" - is called an identity experience in B2C. There are two ways to build one.

User flows are the configured-from-a-form option. You pick a built-in flow type (sign-up and sign-in, password reset, profile editing), pick which identity providers to allow, pick which user attributes to collect, pick which claims to return in the token. No XML, no source control - the configuration lives in the Azure portal. Most teams should start here and stay here.

Custom policies are the configured-from-XML option. They expose B2C's underlying Identity Experience Framework directly, which means you can model journeys user flows do not support - chained REST API calls during sign-up, conditional MFA based on a custom risk signal, multi-step progressive profiling, identity-proofing handoffs to a third-party service. The cost is real complexity: the XML is verbose, the debugging is harder, and the configuration is version-controlled alongside your app rather than clicked in a portal.

The rule of thumb is the one in the docs: reach for custom policies only when a user flow cannot do what you need. They are the escape hatch, not the default.

What you get for free

The reason a managed identity service is worth choosing is not any one feature - it is the pile of things you do not have to build. Out of the box, every B2C tenant gives you:

None of these are checkboxes you have to flip - they come standard. The work of running a customer-facing identity platform is already in the box.

End of sale for new customers

When to reach for it

Inside the existing-customer envelope above, B2C is still a sensible answer when:

• You have a customer-facing application - web, mobile, or both - and you want users to sign in with email, social, or enterprise identities, with managed pages and tokens.
• You want SSO across multiple consumer apps you own, with a single sign-in surface and a single user directory backing all of them.
• You want to federate with another organization's IdP (their Entra tenant, their Okta, their SAML provider) without building a federation broker yourself.
• You need identity attribute storage for up to a hundred custom claims per user, with optional callouts to your own systems via API connectors during sign-up.
• You want MFA, account lockout, and audit logging as platform features rather than as your team's roadmap.

B2C is not the right shape when you need identity for employees - that is what Microsoft Entra ID is for - or when you need a fully self-hosted identity stack you control end to end. For everything in the middle - the customer-facing apps that just need sign-in to work and stop being a maintenance burden - this is the shape of service it covers.