Azure AD B2C is a different animal from standard Azure AD SSO, and conflating the two is the first mistake I see teams make when a client says "we want Azure AD login" but actually means "we want our external customers to log into our Acumatica-backed customer portal with their own accounts." Standard Azure AD federates your own employees, who already exist in your tenant. B2C is for external identities - customers, partners - who don't, and who need to self-register, reset their own passwords, and never see an internal directory.
The use case that actually calls for B2C
The projects where I've reached for B2C specifically involve a customer-facing portal - usually a lightweight custom site or a Acumatica Customer Portal instance - where external users need self-service account creation and password reset without ever touching the client's internal Azure AD tenant. B2C is built for exactly that: a separate, customer-identity-focused Azure AD tenant with its own user flows for sign-up, sign-in, and password reset, issuing tokens Acumatica's OIDC configuration can consume the same way it consumes standard Azure AD tokens. Using B2C for internal staff SSO is the wrong tool - that's what standard Azure AD is for - and using standard Azure AD for thousands of self-registering external customers means every one of them ends up as a directory object in your internal tenant, which most security teams correctly object to.
User flows are the actual configuration surface, not app registration alone
B2C's distinguishing feature is user flows - pre-built, customizable sign-up/sign-in policies that handle the self-service parts standard Azure AD doesn't need to, because standard Azure AD assumes accounts already exist. Configuring the "Sign up and sign in" user flow correctly, including which attributes are collected at registration and which claims get returned in the token, matters more for a B2C integration than the app registration step itself:
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/
{userFlowName}/oauth2/v2.0/authorize
Note the user flow name embedded directly in the URL - a detail that doesn't exist in standard Azure AD's endpoint shape, and one that's easy to get wrong if you copy a standard Azure AD SSO configuration and just swap the tenant name without also swapping in the B2C-specific authority URL format.
External identity needs to map to a business record, not just a login
The part that's genuinely different from an employee SSO setup: a B2C-authenticated external user isn't just logging into a system they already had staff-level access to - their identity needs to resolve to a specific Customer or Contact record so the portal shows only their own orders, invoices, and cases. That mapping has to be built explicitly, usually keyed off the B2C object ID stored against the Contact record at first login:
protected virtual void _(Events.RowSelected<Contact> e)
{
if (e.Row == null) return;
var b2cObjectId = GetCurrentSsoSubjectClaim();
if (e.Row.UsrB2CObjectID != b2cObjectId)
throw new PXException("This portal account is not linked to your login.");
}
Skipping this and trusting a weaker match (email address alone, for instance) is a real data exposure risk - email addresses get reused, mistyped, or shared within a company, and an identity match that isn't tied to the immutable B2C object ID can resolve two different people to the same customer record.
Don't wire B2C sign-up directly to automatic creation of a full Customer record with financial visibility. Land new self-registered users in a pending or unlinked state and require an internal user to associate them with the correct existing Customer record, or your portal becomes a self-service path to accidentally viewing someone else's account if two organizations share a similar name or an internal linking step gets automated carelessly.
Wrapping up
B2C solves a genuinely different problem than standard Azure AD SSO - external, self-registering identities rather than an existing employee directory - and the two shouldn't be conflated during scoping even though both end up as OIDC configuration inside Acumatica. Get the user flow and B2C-specific authority URL right, and treat the mapping from B2C identity to a specific Customer or Contact record as the security-critical step it is, with an explicit linking process rather than an automatic one based on weak matching like email alone.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.