B2C Identity Overview
ThunderID provides the identity layer for customer-facing applications, so your product can focus on the customer experience while ThunderID handles sign-up, sign-in, recovery, profile management, and consent.
If you want the supporting design choices first, start with Architecture Decisions.
When to Choose This Pattern
This pattern is a good fit when you need to:
- Let customers sign up and sign in to your application.
- Support social sign-in, passkeys, or password-based authentication.
- Let customers manage their own profile, credentials, and recovery options.
- Protect customer-facing APIs and application features.
- Collect consent and apply privacy preferences.
- Customize the sign-in experience with your brand.
- You are building a SaaS product for business customers with organizations, tenants, delegated admins, or enterprise onboarding. Use Multi-Tenant SaaS Identity for B2B.
- You are securing autonomous agents, tools, APIs, or machine-to-machine workflows. Use Identity for AI Agents.
How the Model Works
In this pattern, ThunderID acts as the identity provider for your customer-facing application.
- End users own their accounts, sign themselves up, sign in, recover access, and manage their own profile.
- Your application is the web or mobile product the consumer signs into.
- ThunderID runs sign-in, sign-up, recovery, consent, and profile journeys, then issues tokens to the application.
- External identity providers such as Google, GitHub, or enterprise identity providers can be added as sign-in options.
- Internal teams such as support agents and administrators are onboarded separately by invitation or direct account creation.
Building Blocks of the B2C Identity Journey
A B2C identity journey includes one or more of the following building blocks. Each block is a distinct part of the overall customer identity experience, with its own purpose, user experience, and capabilities. Select a block to see what it solves, where it appears in the journey, and which capabilities it uses.
Primary B2C Journeys
Each block below represents a distinct identity use case. Select one to see what it covers and which capabilities are involved.
Add Sign-In to Your Application
Why This Matters
As your most visible identity surface, sign-in needs to feel effortless. Consumers expect to choose the method they already prefer, such as password, social sign-in, passkey, or passwordless sign-in.
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
Authentication methods
- Password sign-in
- Email or SMS one-time code
- Magic link
- Passkey
- Social sign-in
- Enterprise identity provider sign-in
Security controls
- Multi-factor authentication
- Step-up authentication
- Persistent sign-in / remember me
Cross-Cutting Capabilities
These capabilities are not tied to a single journey. They apply across the identity system and are relevant to most B2C applications.
Federated Identity
Why This Matters
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 use.
Capabilities Involved
Identity providers
- Social identity provider sign-in
- Enterprise OIDC identity provider sign-in
- Connected identity sign-out behavior
Account mapping
- Just-in-time account creation
- Account linking
- Federated profile mapping
Next Steps
Once you know which B2C identity building blocks apply, review the architecture decisions that shape your application. Start by choosing an integration pattern, then consider where identities come from, how your APIs validate tokens, and how you run the identity system.
In this step, you can decide:
- Whether to use ThunderID-hosted screens with a redirect-based flow.
- Whether to render app-native screens while ThunderID controls the identity journey.
- Whether to call direct APIs for a more custom implementation.
- Which systems own customer identities.
- How your APIs validate tokens and enforce access.
- How you deploy, monitor, and connect the identity system.
The Architecture Decisions overview helps you work through these choices before you move into implementation.
