Stytch Deep Dive: From B2C Login and Sessions to B2B Organizations and Authorization

🌏 中文版

Stytch is better understood as an API-first managed identity platform than as a “passwordless widget.” It offers prebuilt UI, headless SDKs, and direct APIs, but the selection question is whether it should own the user/member → session → organization → authorization lifecycle for your application.

Stytch separates Consumer Authentication and B2B Authentication into different project and data models. Consumer projects center on a User. B2B projects center on Organizations and Members, allowing the same person to have different membership, roles, and authentication policies in each tenant. The official authentication and authorization guide places SAML/OIDC SSO, SCIM, RBAC, and organization management on the B2B path. Starting with Consumer and recreating tenancy in application tables defeats much of the platform's value.

Layer one: choose the identity primitives

Consumer Authentication fits marketplaces, financial products, and social apps. It supports email magic links, email/SMS/WhatsApp OTP, OAuth, passwords, MFA, WebAuthn/passkeys, and native mobile biometrics. Passwordless is an option rather than a mandate; password flows include strength and breached-password protections.

B2B Authentication makes the organization the ownership boundary. Each enterprise can have its own methods and policies. SSO can JIT-provision members, SCIM can provision or deactivate them, and IdP groups can map to roles. The Discovery flow verifies a person first, issues a short-lived intermediate session for organization selection or creation, and only then exchanges it for a full member session. That separation—who is this person, then which tenant are they entering—is a useful design primitive.

Passkeys have an important boundary. Stytch manages WebAuthn registration and authentication, but its integration guide requires a User to establish a recoverable, verified email, phone, or OAuth factor before registering a passkey. This is an account-recovery design, not a passkey-only first-signup flow with no other identity anchor.

Layer two: converge every factor into a Session

Successful authentication returns an opaque session_token and a session_jwt. The opaque token is checked remotely and can reflect revocation immediately. The JWT can be verified locally with cached JWKS, removing a network hop, but revocation is delayed until the short-lived JWT expires. Stytch's Session documentation also records completed authentication factors, which lets a backend require step-up authentication before sensitive operations.

A minimal B2B protected mutation can combine session validation with an authorization check:

import stytch from "stytch";

const client = new stytch.B2BClient({
  project_id: process.env.STYTCH_PROJECT_ID!,
  secret: process.env.STYTCH_SECRET!,
});

const auth = await client.sessions.authenticate({
  session_token: req.cookies.stytch_session,
  authorization_check: {
    organization_id: req.params.organizationId,
    resource_id: "documents",
    action: "write",
  },
});

await updateDocument(auth.member_id, req.body);

Exact method names should be checked against the pinned SDK version, but the architecture is stable: keep the secret server-side, match the URL organization to the session organization, and authorize before mutation. Hiding a button in React is not authorization; Stytch's permission guide explicitly requires server-side enforcement.

Layer three: organizations are not authorization

An Organization answers “which tenant owns this data?” RBAC answers “what action may this Member perform on this resource?” A Stytch policy contains roles, resources, and actions; session authentication can carry an authorization_check and return 403 when permission is absent. This works for admin/editor/viewer patterns and SCIM role mapping. Per-document sharing, relationship-based access, and rich attribute policies still belong in your application database or a dedicated authorization engine.

For non-human callers, Stytch supports OAuth 2.0 Client Credentials and M2M tokens instead of fake human users. That is useful for services, cron jobs, and agent workloads, but secret rotation, scopes, audiences, short token lifetimes, and auditability remain your responsibility. Machine identity is not workload runtime security.

Fraud and security boundaries

Device Fingerprinting, Protected Auth, invisible CAPTCHA, and new-device detection can address bots, credential stuffing, and trial abuse at authentication. The official risk documentation separates observation from enforcement; observing false positives before blocking is prudent. Magic links are one-time tokens and include handling for enterprise email scanners. High-risk actions still need PKCE where applicable, short redirect tokens, MFA, and transaction-level risk controls. A valid login does not prove a transaction is safe.

Treat identity data as production data. Stytch stores user/member identifiers, authentication factors, organizations, sessions, and possibly device/risk signals. Never expose backend secrets; use Secure, HttpOnly, and appropriate SameSite cookies; verify webhooks; revoke sessions after offboarding or SCIM deprovisioning. Confirm deletion, export, retention, residency, DPA, and workload-specific compliance during procurement rather than inferring them from a certification badge.

Funding and adoption, with provenance

Stytch raised a $90 million Series B at a valuation above $1 billion in 2021. The same TechCrunch report said developers using the platform grew from roughly 350 in July 2021 to about 4,000 that November. That adoption figure came from the CEO at the time; it is not a 2026 production-customer count. Without a reliable current number, inventing a precise figure would be less informative than stating the gap.

As of August 2026, the live pricing page lists a B2B self-serve allowance of 10,000 MAUs/agents, unlimited Organizations, five SSO or SCIM connections, and 1,000 M2M tokens. Overages, SMS/WhatsApp delivery, fingerprints, and branding are separate dimensions. Pricing changes, so model costs with your MAU, enterprise-connection, and OTP-country distribution before committing.

Stytch versus Clerk, WorkOS, and Better Auth

Stytch is a strong fit for teams that understand identity modeling, want headless control, and do not want to build credential and session infrastructure. It is usually excessive for a content site with one social login, a system that must be entirely self-hosted, or an authorization domain dominated by relationship-based policy. The decision is not how many login buttons exist; it is whether you want one managed platform to own long-lived state from factors through sessions and organizations, with acceptable export, migration, and server-side authorization boundaries.

References

• Stytch: Authentication and authorization
• Stytch: B2B Sessions overview
• Stytch: RBAC overview
• Stytch: Fraud & risk protections
• Stytch pricing
• TechCrunch: Stytch raises $90M Series B