Customer Identity for B2C Applications

Build B2C identity where each user owns their account. Users sign themselves up, sign in with the method they prefer, manage their own profile, and recover access when things go wrong.

When to use this pattern

Use this pattern when each user is an individual consumer who owns their own account and registers themselves. They sign in with methods of their choice, such as password, passwordless, social, or passkey.

How the Model Works

• End Users (consumers): own their accounts; sign themselves up, sign in, and manage their own profile.
• Application: the web or mobile product the consumer signs into.
• Identity Provider (IdP): issues identities, runs sign-in / sign-up / recovery journeys, and issues tokens to the application.
• External Identity Providers (optional): external providers (Google, GitHub, enterprise Identity Providers) the application accepts as sign-in options.
• Internal team: the people who run the product (support agents, internal admins, and other operations staff). Onboarded by invitation or created directly, not through consumer self sign-up.

B2C Identity Journey

Every consumer who uses your application goes through an identity journey — signing up for the first time, signing in on return visits, managing their profile, and recovering access when something goes wrong. As the app owner, your job is to make each of these moments seamless and secure, while also onboarding the internal team that keeps the product running. The sections below cover the five core use cases that span this journey.

Add Login to Your Application

As your most visible identity surface, sign-in needs to feel effortless. Consumers expect to choose the method they already prefer — a password, social login, a passkey, or any other passwordless option. Once signed in, they move through your application freely — step-up authentication only comes into play when they attempt something genuinely sensitive. They expect "remember me" to remember them, and they abandon sign-in that is slow, broken, or asks for more than it needs to.

You also need flexibility for different audience segments. A pure consumer application leans on social providers and passwordless methods. A prosumer application needs to accept enterprise identities for users signing in on behalf of their employer. An application handling sensitive data needs step-up authentication that only triggers when the user attempts something risky.

For example, a user installs your mobile application, taps Sign in with Google, and reaches their dashboard within seconds. Later, when they try to change their email address, the application asks them to confirm a one-time code as a step-up check. A power user enables a passkey on their phone and from then on signs in with a single tap of their passkey — no password required.

Capabilities Involved

• Sign-in with password.
• Sign-in with passwordless methods: email or SMS one-time code, magic link, or passkey.
• Sign-in with social providers (Google, GitHub, and others).
• Sign-in via enterprise identity providers (OpenID Connect (OIDC)) for prosumer or mixed audiences.
• Multi-factor authentication.
• Step-up authentication for sensitive operations.
• Persistent sign-in / "remember me".

See it running: Try It Out - Add Login.

Enable Self Sign-Up

New users decide whether your product is worth their time in the first minute. You need a sign-up experience that asks for the minimum information required to get them started. The sign-up method should match what they already use elsewhere. The shorter the form, the higher the completion rate.

Beyond the initial form, you want to verify contact details, capture terms acceptance and marketing consent, and progressively collect additional information as the user engages with features. If they arrive via a federated identity provider, the account is created automatically with their profile pre-populated from the provider — they don't have to retype data the provider already supplied.

For example, a new user lands on your home page, taps Sign up with Google, and arrives signed in with a basic profile already filled in. Their consent decisions are recorded at sign-up time and can be revisited from settings.

Capabilities Involved

• Sign-up with email + password.
• Sign-up with email or SMS one-time code (passwordless).
• Sign-up with a social provider.
• Sign-up with a passkey from the start.
• Progressive profile collection: ask for additional fields only when needed.
• Email / phone verification during sign-up.
• Just-in-time account creation when a federated user lands for the first time.
• Capture terms acceptance and marketing consent.

See it running: Try It Out - Self Sign-Up.

Add Self-Service Profile Management

Once a consumer signs in, they expect a self-service area where they can view and change their own identity without contacting support. This is where they update their name and contact details, swap one sign-in method for another, link or unlink social accounts, and sign out of devices they no longer use. Self-service profile management directly reduces support load and improves user trust.

You also want users to see and control what your application does on their behalf. Granted consents should be visible and revocable. Users should be able to see where they are currently signed in, so they can sign out of any device they no longer control. Sensitive changes such as email, phone, and password should require re-verification so an attacker who hijacks a signed-in session cannot quietly take over the account.

For example, a user opens the account page and switches from password to passkey. They also enable two-factor authentication — the application asks for their phone number and verifies it via a one-time code before activating it. They remove an old linked Google account they no longer use and sign out a session on a device they sold last month. When they change their email address, the new address is verified via a magic link before the change takes effect.

Capabilities Involved

• View and edit profile attributes.
• Change password.
• Add or remove a passkey.
• Manage other second factors (Time-based One-Time Password (TOTP), SMS, and so on).
• Update verified email or phone with re-verification.
• View and withdraw stored consents.
• Manage linked social and enterprise identities.
• View active sessions and revoke a specific session.
• Account deletion or data export.

See it running: Try It Out - Profile Section.

Add Account Recovery

When users lose access to their account, it tests whether they stay or leave. You need recovery paths that are quick when the user is who they say they are, and resistant when they aren't. Multiple recovery channels reduce lockout pain, and verifying the recovery channel itself prevents account takeover through a stale email or recycled phone number.

Different users arrive at recovery with different contexts. Some lost their phone but still have their email. Some lost both and need a fallback channel or a support intervention. Others are locked out after too many failed sign-ins and just need to wait. You want recovery options that match your security policy and each user's verified channels — without adding unnecessary friction.

For example, a user who forgot their password requests a magic link delivered to their email, clicks it, sets a new password, and is signed back in. Another user who lost their phone uses an email one-time code for recovery because their SMS channel is no longer verified. A third, whose account was locked after too many failed attempts, is automatically unlocked after the lockout window expires.

Capabilities Involved

• Forgotten-password reset.
• Passwordless recovery via email magic link.
• Passwordless recovery via email one-time code.
• Passwordless recovery via SMS one-time code.
• Verify the recovery channel before use.
• Account unlock after lockout.

See it running: Try It Out - Account Recovery.

Onboard Internal Users

Behind every consumer product is a team keeping it running — support agents, admins, and operations staff. Onboarding them is different from consumer self sign-up: identity and role are decided up front, before the user arrives. Two patterns cover most cases. The first invites the user by email — they follow a link, set credentials, accept terms, and land signed in. The second creates the account directly, with initial credentials shared out-of-band.

In both patterns the user lands in the right area of the product with the correct role already assigned. Invitation-driven onboarding adds a lifecycle: invitations expire, can be resent, and can be revoked if the wrong person was invited. Direct creation typically skips the acceptance step. It should still walk the user through a first-sign-in flow that requires them to set their own credential. Bulk operations help when onboarding a whole team at once.

For example, a new support agent receives an invitation email and follows the link. They set a password, accept the support terms, and land in the admin console with the support role pre-assigned. Separately, an operations admin creates ten new staff accounts directly for a regional support team. The initial passwords are auto-generated and distributed via a secure channel; the staff members rotate them on first sign-in.

Capabilities Involved

• Invite a user by email.
• Create a user account directly with initial credentials.
• Configurable invitation expiry and resend.
• Revoke a pending invitation.
• Bulk invite or bulk create.
• Single onboarding flow after invitation acceptance (set credential, accept terms, capture profile, and so on).
• Require credential setup on first sign-in for directly created users.
• Assign an initial role or permission set.

See it running: Try It Out - Onboard Internal Users.

Cross-Cutting Capabilities

Beyond the five core use cases, a few capabilities span them all. They are not separate journeys but choices and behaviors that shape sign-in, self sign-up, profile management, recovery, and invitation flows in similar ways. Treat them as decisions you make once and apply consistently.

Federated Identity

External identity providers, both social and enterprise, let users bring an identity they already have to your app. Done well, federation creates one user record per real person regardless of how many sign-in methods they end up using. You want accounts created automatically on first federated sign-in. Those accounts should be linked so one person maps to one account regardless of how they sign in — and signing out should clear all their active sessions.

Authorization

When your app needs to call APIs on behalf of the user, it has to request the right level of access. Scopes describe what the app may do (read profile, send notifications, charge payments, and so on) and audiences describe which API the resulting token is valid for. Request only the scopes the app actually needs; the issued tokens carry those scopes and can be enforced by the API.

Consent

Where authorization describes what the app requests, consent is where the user agrees to it. Three types of consent typically appear together: The first is consent to share specific profile attributes with the app, such as email, name, or phone. The second is consent to the permissions the app has requested. The third is acceptance of the policies you require, such as terms of service, privacy policy, and marketing preferences. Each decision is recorded so the user can review or revoke it later. The record also lets you prove the user agreed if a regulator asks.

Branding

Your sign-in, sign-up, and recovery surfaces should match your brand (colors, logo, and copy) whether they live on hosted pages or inside your own app screens. The user should not notice they crossed a boundary into an identity product.

Privacy

Consent capture and policy alignment should be built into registration and ongoing profile interactions, not bolted on later. The user should be able to see what's stored about them, what's been shared with which connected application, and how to delete or export their data.

---

Next Steps

Once you know which use cases apply, the next step is deciding how to integrate. See Solution Patterns to compare integration approaches and find the right fit for your application.

Related Capabilities

Flows

Sign-in, sign-up, and recovery journeys.

Passkeys

Phishing-resistant sign-in.

Federation

Social and enterprise identity providers.

Consent

Capture and revisit consent decisions.

Recovery

Multiple recovery channels.

Invitations

Onboard your internal team.