Category: Customer Identity

B2C Identity

Also known as: B2C, Business-to-Customer Identity, Business-to-Consumer Identity, Customer Identity

Simply put

B2C identity refers to the practice of managing the digital identities of an organization's external customers or consumers, as opposed to its internal employees. It lets customers sign in to an organization's applications using accounts they already have, such as social or other external logins, and covers verifying who they are (authentication) and, depending on the service, what they are permitted to do (authorization). Cloud services such as Azure Active Directory B2C provide this capability as a managed service.

Formal definition

B2C identity is a customer-facing identity model that provides authentication and, depending on configuration, authorization services for external consumers rather than workforce users. Platforms in this category, such as Azure Active Directory B2C, typically operate as a directory service and identity provider that can federate to external identity stores and social, enterprise, or other identity providers. According to the evidence, Azure AD B2C supports federation via OpenID Connect (for example, through a custom identity provider integration) and is described as a directory and authentication service that leverages identity stores outside the organization. Note that the evidence does not detail the specific access control model, token formats, or protocol profiles beyond the OpenID Connect reference, so those aspects are out of scope for this entry.

Why it matters

B2C identity addresses a fundamentally different population than workforce identity: external customers or consumers who choose whether and how to engage with an organization's applications. Unlike employees, who are onboarded through HR-driven provisioning and governed by internal policy, customers expect low-friction registration and sign-in, often using accounts they already hold. Getting this wrong, through cumbersome onboarding, brittle authentication, or poor account recovery, directly affects customer acquisition and retention, which makes B2C identity a business concern as much as a security one.

Separating customer identity from workforce identity also matters for the integrity of both. Mixing external consumer accounts into the same directory and policy structures used for internal employees can blur trust boundaries and complicate governance. Purpose-built B2C services, such as Azure Active Directory B2C, address this by operating as a distinct directory and authentication service that leverages identity stores outside the organization and can federate to social, enterprise, or other external identity providers. This lets organizations meet customers where they already have accounts while keeping consumer identity concerns architecturally distinct from employee access.

Because customer-facing sign-in is exposed to the public internet at scale, the authentication surface it presents is a natural target. Treating B2C identity as a dedicated capability, rather than an afterthought bolted onto a workforce directory, helps organizations reason clearly about how customers are identified, authenticated, and, depending on the service, authorized, without conflating those steps with internal access enforcement.

Who it's relevant to

Security architects

Architects designing customer-facing applications use B2C identity to keep consumer authentication architecturally distinct from workforce identity. Understanding that a service like Azure AD B2C functions as a separate directory and identity provider that can federate to external and social identity providers helps them draw trust boundaries correctly and decide where authentication and any authorization decisions occur.

IAM engineers

Engineers implementing and integrating customer sign-in work directly with federation configurations, for example, wiring up an external or custom identity provider to Azure AD B2C via OpenID Connect. They need to distinguish the customer identity provider role from workforce systems and configure the authentication flow that lets consumers use accounts they already hold.

Compliance and identity governance leads

Governance stakeholders benefit from separating consumer identity from employee identity so that lifecycle, data handling, and access concerns for external customers are not blurred with internal workforce governance. Note that the evidence does not detail specific governance, access review, or access control model behavior for this service, so those aspects should be validated against the chosen platform and deployment.

Application and product owners

Owners of customer-facing products care that sign-in is low-friction and lets customers use their preferred social, enterprise, or other external accounts. A managed B2C service offloads the directory and authentication work, though the specific authorization behavior available to a given application depends on how the service is configured.

Inside B2C

Customer Identity Repository

A directory or identity store holding consumer profiles, credentials, and associated attributes. In B2C deployments this is typically optimized for large scale (millions of records) and self-service, and may be an LDAP directory, a cloud-native store, or a purpose-built CIAM datastore, depending on the platform.

Self-Service Registration and Progressive Profiling

Flows that let consumers create their own accounts (identification and initial credential enrollment) and that collect additional attributes incrementally over time rather than all at once. This distinguishes B2C onboarding from workforce provisioning, which is typically administrator-driven.

Authentication Options

The mechanisms used to verify a returning consumer, which may include knowledge factors (passwords), possession factors, inherence factors, MFA, step-up authentication for sensitive actions, and increasingly passwordless options such as passkeys built on WebAuthn/FIDO2. The exact set available depends on the CIAM platform and configuration.

Social Login / Identity Federation

The ability for consumers to authenticate through external identity providers. This is commonly implemented using OpenID Connect (the authentication layer over OAuth 2.0) or, in some web SSO contexts, SAML 2.0. OAuth 2.0 alone provides delegated authorization and is not by itself an authentication mechanism.

Consent and Privacy Management

Facilities for capturing, recording, and honoring consumer consent for data collection and processing, along with preference management. These concerns are more prominent in B2C than in workforce identity because of consumer privacy expectations and applicable regulations.

Token Issuance and Session Management

Runtime issuance and handling of tokens after authentication. Depending on the protocol and profile this can include OIDC ID tokens (asserting authentication), OAuth 2.0 access tokens (authorizing API access), and refresh tokens. Tokens may be opaque or self-contained (such as JWTs); note that signing a token provides integrity, not confidentiality.

Authorization Enforcement

The runtime determination of what a consumer may do after they are authenticated, distinct from authentication itself. Depending on the deployment this may draw on models such as RBAC, ABAC, or ReBAC, and involves enforcement components (PEP) consulting decision logic (PDP).

Common questions

Answers to the questions practitioners most commonly ask about B2C.

Is B2C identity just the same as consumer authentication?

No. Authentication, verifying who a consumer is, is only one part of B2C identity. A complete B2C identity program also covers identification (how a person is first recognized in the system, often via self-service registration), authorization (what the authenticated consumer may access or do), and the surrounding lifecycle concerns such as consent capture, profile management, and account recovery. Treating B2C identity as authentication alone omits the authorization decisions and governance that follow login.

Does using OAuth 2.0 in a B2C flow mean I'm authenticating my consumers?

Not by itself. OAuth 2.0 is a delegated authorization framework; it governs how an application obtains access to resources on a principal's behalf, not how the consumer's identity is verified. For authentication in a B2C context you typically layer OpenID Connect (OIDC Core) on top of OAuth 2.0, which introduces the ID token that conveys authentication claims about the consumer. Relying on OAuth 2.0 access tokens as proof of who the user is conflates authorization with authentication.

How do B2C identity systems typically handle self-service registration and account recovery?

In most B2C deployments, registration is self-service, meaning consumers create their own accounts rather than being provisioned by an administrator, which differs from the workforce model. Recovery flows must therefore be designed to re-verify a returning consumer using factors under their control. The specific mechanisms vary by vendor and deployment context, so the balance between friction and assurance should be defined per use case rather than assumed.

Where do passwordless options like passkeys fit into a B2C authentication strategy?

Passkeys are a consumer-facing form of passwordless authentication built on FIDO2 and WebAuthn, and they are increasingly offered in B2C flows to reduce reliance on knowledge-factor passwords. They are not interchangeable synonyms: WebAuthn is the web API, FIDO2 is the broader specification set it belongs to, and passkeys are the credential experience presented to users. Whether passkeys, other MFA methods, or step-up authentication are appropriate depends on the risk of the action and your deployment configuration.

How should consent and profile data be managed alongside authentication in B2C identity?

Consent capture and profile management are typically distinct concerns from the authentication event itself and are often treated as part of the consumer identity lifecycle. Depending on configuration, consent decisions may drive later authorization outcomes, so it is useful to keep the record of what a consumer agreed to separate from the runtime enforcement that acts on it. The exact data model and storage vary by platform.

What token types are commonly involved when a consumer signs in to a B2C application?

In an OIDC-based B2C sign-in, you typically encounter an ID token that carries authentication claims about the consumer, an access token used to authorize calls to protected resources, and often a refresh token used to obtain new tokens without re-prompting the user. These serve different purposes and should not be used interchangeably; in particular, an access token is not intended as proof of the consumer's identity. Note also that a signed token is not necessarily encrypted, so token contents may be readable unless additional protection is applied.

Common misconceptions

Social login means OAuth 2.0 is authenticating the consumer.

OAuth 2.0 is a delegated authorization framework and is not, on its own, an authentication protocol. Consumer authentication via an external provider is typically achieved with OpenID Connect, which adds an authentication layer (including the ID token) on top of OAuth 2.0.

B2C identity is just workforce IAM applied to consumers.

B2C identity typically emphasizes self-service registration, progressive profiling, consent and privacy management, social login, and very large scale, whereas workforce identity is typically administrator-driven and centered on provisioning and governance. The lifecycle, scale, and privacy expectations differ substantially.

Passkeys, WebAuthn, and FIDO2 are interchangeable terms for the same thing.

They are related but distinct. FIDO2 is the overarching set of specifications, WebAuthn is the web API component within it, and passkeys are FIDO2 credentials (often synced across devices) that enable passwordless authentication. They should not be treated as synonyms.

Best practices

Keep identification, authentication, and authorization as separate steps in the consumer access flow, and design each independently rather than assuming one implies the others.

When implementing social login, use OpenID Connect for authentication rather than relying on OAuth 2.0 alone, and validate ID tokens according to the OIDC Core profile in use.

Offer and prioritize phishing-resistant passwordless options such as passkeys (built on WebAuthn/FIDO2) where the platform supports them, and apply step-up authentication for sensitive consumer actions.

Capture and honor consumer consent explicitly, and use progressive profiling to collect attributes over time rather than demanding all data at registration.

Treat token security carefully: choose opaque or self-contained tokens deliberately, and remember that signing a token ensures integrity but not confidentiality, so encrypt tokens or protect them in transit where sensitive claims are involved.

Separate identity governance concerns (such as profile lifecycle and access reviews) from runtime enforcement components (PDP, PEP, PIP, token validation) so that lifecycle changes and real-time decisions remain distinct and auditable.