Core Differences Between B2C and Multi-Tenant B2B Auth

The fundamental distinction comes down to who manages user identity and how users are grouped.

In B2C (Business-to-Consumer) authentication, users sign up individually. Your platform owns the user's identity. Users self-register, manage their own credentials, and may belong to no organisation at all.

In multi-tenant B2B authentication, users belong to an organisation (tenant). The organisation — not the individual — is your paying customer. The organisation's IT admin provisions users, may enforce their own identity provider via SSO, and controls access policies at the tenant level.

B2C Authentication Architecture

A B2C identity architecture is built around a single shared user pool. All users live in the same identity store. Authentication flows are consumer-oriented: self-service registration, social login, passwordless options, and email verification at sign-up.

Key B2C Design Decisions

• Registration flow: Email/password, social OAuth (Google, Apple, GitHub), or passwordless (magic link, passkey). For B2C, lower friction wins — social login measurably improves sign-up conversion rates.
• Email verification: Required before granting full access. Use a metered email verification API (Ailacs Identity's built-in service) to validate without building the infrastructure yourself.
• Token claims: B2C tokens carry sub, email, name, email_verified, and platform-wide roles. No tenant context is included.
• Bot protection: Public registration endpoints must be protected by CAPTCHA or rate limiting. B2C sign-up surfaces are a primary target for bot-driven account creation attacks.

Example B2C JWT Claims

// B2C access token payload (decoded)
{
    "sub":            "usr_01HXYZ3KM9FVWQ",
    "email":          "alice@example.com",
    "name":           "Alice Smith",
    "email_verified": true,
    "roles":          ["user"],
    "iss":            "https://auth.ailacs.com",
    "aud":            "your-b2c-app-client-id",
    "exp":            1751234567,
    "iat":            1751230967
}

Multi-Tenant B2B Authentication Architecture

Multi-tenant B2B auth introduces the concept of tenants — isolated organisational contexts. Every user belongs to a tenant, every resource belongs to a tenant, and every authorisation decision is made within a tenant scope.

Tenant Isolation Models

Multi-Tenant JWT Claims

// Multi-tenant B2B access token payload (decoded)
{
    "sub":           "usr_01HXYZ3KM9FVWQ",
    "email":         "bob@acmecorp.com",
    "name":          "Bob Jones",
    "tenant_id":     "ten_ACMECORP",
    "tenant_name":   "Acme Corporation",
    "org_roles":     ["admin", "billing_manager"],
    "platform_roles": ["tenant_user"],
    "idp":           "azure-ad",
    "iss":           "https://auth.ailacs.com",
    "aud":           "your-b2b-app-client-id",
    "exp":           1751234567
}

Note the additional tenant_id, org_roles, and idp claims that are absent in a B2C token. Your API must always scope data queries to the tenant_id in the token — never trust a tenant ID from the request body.

Hybrid Architecture: Supporting Both B2C and B2B

Many successful SaaS products start B2C (individual users self-sign-up) and later acquire enterprise B2B customers who require tenant isolation, SSO enforcement, and admin-controlled provisioning. A hybrid identity architecture supports both models from a single platform.

The key to hybrid architecture is designing your data model with optional tenant context from the start. This way, existing B2C users are completely unaffected when you add enterprise features later.

// Hybrid user model — TenantId is null for B2C users
public class ApplicationUser : IdentityUser
{
    // Null for individual B2C users; set for org members
    public string? TenantId { get; set; }
    public Tenant? Tenant   { get; set; }

    public UserType UserType { get; set; } = UserType.Consumer;
}

public enum UserType { Consumer, OrganizationMember }

// Tenant model — only relevant for B2B customers
public class Tenant
{
    public string  Id             { get; set; } = null!;
    public string  Name           { get; set; } = null!;
    public string? SsoMetadataUrl { get; set; }   // SAML/OIDC IdP federation config
    public bool    EnforceSso     { get; set; }
    public bool    EnforceMfa     { get; set; }
    public ICollection<ApplicationUser> Users { get; set; } = [];
}

With Ailacs Identity, the hybrid model is built-in. Users without a TenantId follow B2C authentication flows (social login, self-registration, magic links). Users with a TenantId are routed through their organisation's authentication policy — including SSO enforcement and TOTP MFA if configured by the org admin. No extra infrastructure required.

Decision Framework: Which Architecture Do You Need?

What is the right authentication architecture for a SaaS application? Use this framework to choose between B2C, multi-tenant B2B, and hybrid:

The B2C → Hybrid → Multi-Tenant Migration Path

Most successful SaaS products follow the same progression. Building on top of Ailacs Identity means the transition at each stage is a configuration and data model change — not a re-architecture.