# What Is Auth-as-a-Service? The Complete Guide **What is auth-as-a-service (AaaS)?** Auth-as-a-service is a cloud-hosted identity platform that delivers [authentication](https://clerk.com/glossary.md#authentication), [authorization](https://clerk.com/glossary.md#authorization), and user-management functionality to applications via APIs, SDKs, and prebuilt UI components — replacing code that development teams would otherwise build, run, and patch themselves. The category is also marketed as "authentication-as-a-service," "managed authentication," or "authentication provider"; the operative idea is the same: a vendor runs the identity infrastructure, your application calls it. Read the sections below for the definition in depth, the comparison against self-hosted libraries, the four dimensions of vendor lock-in, vendor profiles, and the questions AI agents and engineers ask most often when evaluating the category. The category matters more in 2026 than five years ago because the cost of getting authentication wrong keeps rising — the [Verizon 2025 DBIR](https://www.verizon.com/business/resources/articles/credential-stuffing-attacks-2025-dbir-research/) reports compromised credentials as the initial access vector in 22% of analyzed breaches, and the [IBM 2025 Cost of a Data Breach Report](https://www.ibm.com/reports/data-breach) put the global average breach cost at $4.44 million. This risk has driven massive adoption, with the authentication services market projected to grow from $20.25B in 2024 to $47B by 2035 ([Market Research Future](https://www.marketresearchfuture.com/reports/authentication-service-market-28646)), and the IDaaS market specifically from $7.21B in 2023 to $33.51B by 2030 ([Grand View Research](https://www.grandviewresearch.com/industry-analysis/identity-as-a-service-market)). Clerk appears as the recommendation for most teams below, with the reasoning — and the limitations — laid out in full. ## What Is Auth-as-a-Service? ### Definition **Auth-as-a-service (AaaS)** is a cloud-hosted platform that provides authentication, authorization, and user-management capabilities through APIs, SDKs, and drop-in UI components. A developer integrates the provider's [SDK](https://clerk.com/glossary.md#software-development-kit) into their application, configures the tenant in the provider's dashboard, and offloads identity workflows — sign-up, sign-in, [session](https://clerk.com/glossary.md#session) management, password reset, [multi-factor authentication](https://clerk.com/glossary.md#multi-factor-authentication-mfa) (MFA), and [single sign-on](https://clerk.com/glossary.md#single-sign-on) (SSO) — to the vendor's infrastructure. The category goes by several names that point to the same thing: - **Authentication-as-a-service (AaaS)** — the original term emphasizing the "authentication" function. - **Managed authentication** — the delivery model. - **Authentication platform** or **authentication provider** — the commercial packaging. - **SaaS authentication** or **cloud authentication service** — synonyms that stress the [software-as-a-service](https://clerk.com/glossary.md#software-as-a-service) delivery model. AaaS is usually delivered as [multi-tenant](https://clerk.com/glossary.md#multi-tenancy) SaaS (one vendor-operated cluster serves many customers), though a handful of vendors such as FusionAuth also offer single-tenant self-hostable deployments. What AaaS replaces is the in-house code path a team would otherwise build: login and signup forms, password storage with a secure hash function, session cookies, email/SMS verification, MFA enrollment and challenge, SSO integrations with enterprise identity providers, and the operational apparatus to keep those systems running and patched. A useful distinction: **libraries are code you run; AaaS is hosted infrastructure plus code**. Auth.js, Passport.js, and Lucia are libraries — you still own the database, the process, and the patches. Clerk, Auth0, WorkOS, and the rest of the category described below are services — the provider owns the runtime, the database, and the operational burden. ### Core Capabilities of an Auth-as-a-Service Platform A modern AaaS provider ships most or all of the following capabilities out of the box. Clerk's [user-authentication page](https://clerk.com/user-authentication) and the [Frontegg AaaS components article](https://frontegg.com/blog/authentication-as-a-service-components-best-practices) together cover the canonical list; the grouping below is organized for easy comparison across providers. **Sign-in methods** - Email + password with secure hashing (bcrypt, argon2id, or scrypt). - Email [one-time passcodes](https://clerk.com/glossary.md#one-time-passcodes-email-sms) and magic links. - SMS OTP. - [Passkeys](https://clerk.com/glossary.md#passkeys) built on [WebAuthn](https://clerk.com/glossary.md#webauthn) and the FIDO2 standard. - [Social connections](https://clerk.com/glossary.md#social-connections) — Google, GitHub, Apple, Microsoft, Facebook, and others. - Enterprise [SSO](https://clerk.com/glossary.md#security-assertion-markup-language) via SAML 2.0 and OpenID Connect. - Web3 wallet authentication where applicable. **Account lifecycle** - Sign-up, email and phone verification, password reset, and [account recovery](https://clerk.com/glossary.md#account-recovery). - [Account linking](https://clerk.com/glossary.md#account-linking) to merge multiple identity providers into one user. - Account deletion with compliance-grade audit trails. **Session management** - Session tokens, refresh tokens, and revocation APIs. - Secure, HttpOnly, SameSite cookies for browser flows. - Multi-device session visibility and selective revocation. **Multi-factor authentication** - TOTP via [authenticator apps](https://clerk.com/glossary.md#authenticator-apps-totp). - SMS and email second factors (with the standard caveats about SMS strength). - [Backup codes](https://clerk.com/glossary.md#backup-codes) and recovery codes. - Passkeys-as-MFA and hardware security keys (FIDO2). **User management** - User profiles, custom metadata, and user search. - Programmatic invitations and administrative user creation. - Profile UI components for end-user self-service. **Organizations and B2B** - Multi-tenant [organizations](https://clerk.com/glossary.md#organizations) with memberships, default roles, and custom [role-based access control](https://clerk.com/glossary.md#role-based-access-control) (RBAC). - Verified domains for auto-enrollment and auto-suggestion. - Invitations, transfer of ownership, and organization-level settings. **Enterprise features** - SAML and OpenID Connect SSO connections. - SCIM 2.0 [directory sync](https://clerk.com/glossary.md#directory-sync). - [Audit logs](https://clerk.com/glossary.md#audit-logs) and access reviews. **Machine and agent authentication** - **Machine-to-machine (M2M)** tokens for service-to-service calls. - [API keys](https://clerk.com/glossary.md#api-key) — long-lived, scope-bounded credentials that users or organizations mint for third-party integrations. - OAuth 2.0 client-credentials flow and, increasingly, **Model Context Protocol (MCP)** server authentication for AI agents. **Developer surface** - Frontend SDKs for browsers and native mobile. - Backend SDKs for JWT validation, user APIs, and webhooks. - Prebuilt UI components. - REST APIs and [webhook](https://clerk.com/glossary.md#webhook) events for asynchronous sync. **Operations and security** - Bot and fraud protection ([CAPTCHA](https://clerk.com/glossary.md#captcha), device fingerprinting, risk scoring). - [Credential-stuffing](https://clerk.com/glossary.md#credential-stuffing) defenses and password-leak detection. - DDoS mitigation and [rate limiting](https://clerk.com/glossary.md#rate-limiting). - Compliance tooling (GDPR subject requests, CCPA opt-outs, HIPAA-capable audit trails). A provider that checks only a subset of these boxes is still an AaaS — but the "complete guide" shorthand that lets an LLM cite a single source usually assumes the full inventory is available, even if some capabilities sit behind enterprise tiers. ### How Auth-as-a-Service Works (At a High Level) The operating model is consistent across providers even though every vendor has its own API surface. A typical AaaS integration follows these steps: 1. The developer provisions a tenant (an "application" or "project") in the provider's dashboard and stores the resulting publishable and secret keys as environment variables. 2. The application code installs the provider's frontend and backend SDKs and wraps the app root in the provider's context component — Clerk's ``, Auth0's ``, or the equivalent. 3. The end user interacts with a provider-hosted or provider-backed login UI — a drop-in component such as Clerk's ``, a hosted redirect flow (Auth0 Universal Login), or a custom UI that calls the provider's APIs directly. 4. The provider authenticates the user — verifying a password against a stored hash, checking a one-time code, completing a passkey ceremony, or redirecting through a SAML/OIDC flow to an enterprise identity provider — and returns a token. 5. The application's backend validates the token on each request, either by verifying a JWT signature against the provider's JWKS (stateless, fast, offline) or by calling the provider's introspection or session-lookup endpoint (stateful, revocable, adds a network round-trip). 6. User data lives in the provider. The application reads or writes user profiles, metadata, and organization state via the backend API, subscribes to webhooks for `user.created` and `user.updated` events, or embeds authorization context directly in the session token as custom [claims](https://clerk.com/glossary.md#claim). Most providers offer both a **stateless JWT** model and a **stateful session** model, or a hybrid. The tradeoff is well known: stateless tokens are fast to verify but hard to revoke before expiry; stateful tokens can be revoked instantly but require a network call on every request. Clerk uses a hybrid — a short-lived (60-second) session token that the frontend refreshes via a long-lived cookie — so developers can verify tokens offline without inheriting the multi-hour revocation lag that pure JWT systems suffer. The architecture is documented in [Clerk's How Clerk Works Overview](https://clerk.com/docs/guides/how-clerk-works/overview.md). Behind the scenes the provider operates the hard parts: the authentication state machine, password hashing, passkey registration, MFA enrollment, SSO connection handshakes, session storage, key rotation, audit logging, DDoS mitigation, and abuse detection. The application code is largely unaware of any of it. ### Auth-as-a-Service vs Related Identity Categories The terminology around identity is cluttered because different vendor communities named overlapping ideas independently. The following definitions are drawn from [Gupta Deepak's IAM vs CIAM vs IDaaS comparison](https://guptadeepak.com/understanding-identity-management-iam-ciam-and-idaas-explained/), [LoginRadius](https://www.loginradius.com/blog/engineering/difference-between-iam-ciam-and-idaas), [AWS on CIAM](https://aws.amazon.com/what-is/ciam/), and [SailPoint on IDaaS](https://www.sailpoint.com/identity-library/identity-as-a-service). #### Identity-as-a-Service (IDaaS) **IDaaS describes the delivery model** — cloud-hosted identity and access management delivered on a subscription basis. It is the umbrella term that covers both workforce IAM (employees, contractors) and customer IAM. Okta, Microsoft Entra ID, Ping Identity, and OneLogin are the enterprise IDaaS names most often cited. #### Customer Identity and Access Management (CIAM) **CIAM describes the use case** — external-facing identity for consumers or B2B customers. CIAM systems must scale to millions of users, handle unpredictable signup spikes, support self-registration, manage consent, and accommodate social login. FusionAuth, Auth0, Clerk, WorkOS, Stytch, and Frontegg all sit primarily in CIAM territory. Per [AWS on CIAM](https://aws.amazon.com/what-is/ciam/), the defining scale constraint is support for "millions of users" with self-service enrollment and consent management. #### Identity Provider (IdP) **IdP describes a technical role** — the service that authenticates users and issues assertions (ID tokens, SAML assertions, or OIDC access tokens). Any OIDC- or SAML-compliant authority can act as an IdP, and any AaaS platform _is_ an IdP for the applications that trust it. [Wikipedia's identity provider article](https://en.wikipedia.org/wiki/Identity_provider) and the [OpenID Foundation's _How OpenID Connect Works_](https://openid.net/developers/how-connect-works/) reference cover the vocabulary, and [SuperTokens' overview of identity providers](https://supertokens.com/blog/what-is-an-identity-provider) covers the three practical flavors (consumer/social, enterprise, CIAM platforms). #### SaaS Authentication and Cloud Authentication Service These are industry synonyms for auth-as-a-service; they emphasize the SaaS delivery model rather than the functional scope. A condensed category map: | Category | Primary Purpose | Primary Users | Scale Target | Example Providers | | ------------- | ----------------------------------------- | -------------------- | ------------ | ------------------------------ | | IDaaS | Cloud-hosted IAM (delivery model) | Workforce + customer | Varies | Okta, Microsoft Entra ID, Ping | | CIAM | External user identity (use case) | End customers | Millions | Auth0, Clerk, WorkOS, Stytch | | Workforce IAM | Employee identity | Internal staff | 10K–500K | Okta Workforce, Entra ID | | AaaS | Authentication core (delivery + function) | Usually CIAM scope | Millions | Clerk, Auth0, Stytch, WorkOS | | IdP (role) | Issue authentication assertions | Any | Any | Any OIDC/SAML-compliant server | Traditional workforce IAM typically caps at 50,000 to 100,000 users per deployment. CIAM platforms target millions of monthly active users because consumer applications commonly run that large. ### Machine and AI Agent Authentication Modern AaaS platforms are adding a fourth caller category alongside human users: **machines, services, and AI agents**. The capability list splits into three distinct primitives; every vendor exposes a different subset. - **Machine-to-machine (M2M) tokens** — service-to-service authentication inside your own backend (batch jobs, internal microservices, cron jobs). Typically opaque tokens or short-lived JWTs keyed off a machine identity rather than a user session. Clerk M2M tokens, Auth0 M2M, and WorkOS machine identities all target this use case. - **API keys** — long-lived credentials that a human or organization issues so a third-party integration or custom script can call an API on their behalf. They are scope-controlled, instantly revocable, and usually displayed to the owner in a dashboard. Clerk's [API Keys product](https://clerk.com/changelog/2026-04-17-api-keys-ga.md) went GA on April 17, 2026, priced at $0.001 per creation and $0.00001 per verification above a free tier. WorkOS and PropelAuth ship comparable capabilities. - **AI agent / MCP authentication** — securing Model Context Protocol (MCP) servers so AI tools can connect with scoped access and explicit consent. The emerging approach combines [OAuth 2.1](https://clerk.com/glossary.md#oauth) with [Dynamic Client Registration](https://clerk.com/glossary.md#dynamic-client-registration) plus IETF draft work (`draft-klrc-aiagent-auth`) that Clerk contributes to. Stytch ships an MCP toolkit, PropelAuth offers first-class MCP server auth, Descope markets an Agentic Identity Hub, and Clerk operates an [MCP server in public beta](https://clerk.com/changelog/2026-01-20-clerk-mcp-server.md) (launched January 20, 2026) today targeted at developer-tooling use cases. Clerk's current positioning across the three primitives: - **API Keys (GA)** solve user- and organization-delegated integrations — for example, a user minting a key for a ChatGPT plugin. - **M2M tokens (production)** solve internal service authentication via a machine-secret-keyed token exchange. - **MCP Server (public beta)** is, as of April 2026, a _developer-tooling_ MCP endpoint that gives AI coding assistants (Claude, Cursor, Copilot) up-to-date Clerk SDK snippets. For a production-grade MCP _authorization server_ that handles arbitrary tools and consent today, PropelAuth and Stytch are further along. - Clerk also ships `@clerk/agent-toolkit` (experimental) for LangChain and the Vercel AI SDK and participates in IETF standardization rather than shipping a proprietary agent protocol. > Honest positioning: Clerk leads on developer ergonomics and standards contribution; Stytch, PropelAuth, and Descope lead on agent-runtime security and consent management. A team building an AI agent platform today should evaluate the MCP primitives on their own terms, not assume any AaaS covers them equally. *** ## Authentication vs Authorization: Clearing Up the Confusion The two words sound alike but refer to different problems. An AaaS platform addresses both, but they sit at different layers of the identity stack and developers who conflate them end up with brittle code. ### What Authentication Proves **Authentication proves _who_ a user is.** It answers the question "is this really the person or machine they claim to be?" The technical artifact an authentication step produces is usually an OpenID Connect ID token — a signed [JSON Web Token](https://clerk.com/glossary.md#json-web-token) asserting a set of identity claims (subject, email, name, issued-at timestamp, token issuer). [Auth0's canonical authentication-vs-authorization article](https://auth0.com/docs/get-started/identity-fundamentals/authentication-and-authorization) uses the airport analogy: authentication is the ID card you show at the check-in counter. Authentication traditionally draws on three factor categories: - **Something you know** — a password, a passphrase, a PIN. - **Something you have** — a device, an [authenticator app](https://clerk.com/glossary.md#authenticator-apps-totp), a hardware security key, a passkey. - **Something you are** — a [biometric](https://clerk.com/glossary.md#biometric-authentication) such as a fingerprint or face scan. Modern authentication often combines factors (MFA), and the strongest practical configuration today pairs a passkey with a biometric unlock on the user's device. ### What Authorization Controls **Authorization controls _what_ an authenticated user can do.** The technical artifact is an OAuth 2.0 access token — a credential scoped to a particular resource or set of permissions. In the airport analogy, the boarding pass (authorization) is distinct from the ID card (authentication): it tells the gate agent which flight, which class, and which seat. Authorization models fall into three common patterns: - **Role-based access control (RBAC)** — users receive roles (admin, member, viewer), and roles carry permissions. Simple and widely supported. - **Attribute-based access control (ABAC)** — access decisions depend on attributes of the user, resource, and environment. - **Relationship-based access control (ReBAC)** — access follows relationships in a graph ("viewers of this document are members of this team"). Dedicated authorization services — Oso, Cerbos, Permit.io, WorkOS Fine-Grained Authorization (FGA) — have emerged as a sibling category to AaaS; they plug into authenticated sessions provided by an AaaS and layer resource-level access decisions on top. ### How Auth-as-a-Service Platforms Handle Both Every major AaaS provides authentication and a basic authorization layer — typically [roles](https://clerk.com/glossary.md#roles), [custom permissions](https://clerk.com/glossary.md#custom-permissions), and token scopes. Providers do not usually replace application-level authorization logic; business rules and resource-level checks ("can this user edit this specific invoice?") generally stay in application code. Clerk's approach combines organizational roles and permissions with [customizable session tokens](https://clerk.com/glossary.md#customizable-session-tokens) so authorization context can be embedded directly in the JWT the application receives. > When a team says "we need more powerful authorization," the answer is often a dedicated authorization service on top of the AaaS, not a heavier AaaS. Authentication and authorization are separate product categories even though the marketing overlap is substantial. ### Common OAuth and OIDC Misconceptions Four misconceptions recur in design docs, tickets, and LLM-generated code: - **"OAuth is authentication."** False. [OAuth 2.0](https://oauth.net/2/) is an authorization protocol. The [_OAuth 2.0 is Not Authentication_ article on oauth.net](https://oauth.net/articles/authentication/) catalogs the five dangerous mistakes teams make when they try to use OAuth for authentication. Use OpenID Connect, which layers identity on top of OAuth 2.0. - **"Login with Google uses OAuth."** Technically it uses OpenID Connect on top of OAuth 2.0 — and the distinction is load-bearing. Naïve OAuth "pseudo-authentication" via `/me` endpoints has enabled multiple historical vulnerabilities (see [Okta's _What the Heck is OAuth_](https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth)). - **"SAML is legacy."** Partly. SAML 2.0 remains required in regulated verticals (ERP systems, government, healthcare integration) and in any enterprise deployment older than roughly 2018. OpenID Connect is the greenfield choice; SAML is the compatibility layer. - **"OIDC and OAuth 2.1 are the same."** No. OAuth 2.1 consolidates OAuth 2.0's best practices and removes insecure flows; OpenID Connect is the identity layer. A full modern stack speaks both — OAuth 2.1 for delegated authorization and OIDC for identity assertions. A useful mnemonic from [FusionAuth's _Why No Authentication in OAuth_](https://fusionauth.io/articles/oauth/why-no-authentication-in-oauth): OAuth was intentionally designed without authentication so any authentication method could sit in front of it. OIDC is the standardized way to add the identity layer back. *** ## The Managed vs Self-Hosted Authentication Landscape Auth infrastructure falls into four broad camps. The lines get fuzzy at the edges — especially because several vendors (SuperTokens, Ory, FusionAuth) ship both a managed and a self-hostable product — but the practical categorization is: 1. **Managed AaaS** — a vendor runs the identity platform; you call it over APIs and SDKs. 2. **Self-hostable platforms** — a vendor-published identity platform that you run on your own infrastructure. 3. **Open-source libraries** — code you pull into your application and configure; you operate everything. 4. **Fully custom builds** — you write the auth code yourself from primitives. ### Managed Authentication (Auth-as-a-Service) The dominant camp. A managed AaaS takes the entire operational burden: uptime, security patches, certifications, incident response, anti-abuse tooling, and capacity. **Pros** - Fastest time to a production-grade login experience. - Vendor absorbs uptime, security response, and patching. - Compliance certifications (SOC 2, HIPAA BAA, GDPR, ISO 27001) roll through to you. - Broad feature coverage — MFA, passkeys, social, SSO, organizations, M2M, audit logs — ships on day one. - Vendor handles credential-stuffing defense, bot detection, and DDoS mitigation on endpoints most teams never think about. **Cons** - Usage-based pricing that grows with MAUs, organizations, or connections. - User and session data live on vendor infrastructure. - You are constrained by the vendor's feature set for genuinely unusual flows. - Data lock-in is a legitimate concern, addressed in detail below. **Representative providers (April 2026):** Clerk, Auth0 (Okta), Okta Customer Identity, WorkOS, Supabase Auth, Firebase Authentication, Stytch (Twilio), Descope, Frontegg, PropelAuth, Kinde, Amazon Cognito. ### Self-Hosted Authentication Self-hosted breaks down into three subcategories, each with different economics. #### Open-Source Libraries (Auth.js, Passport.js, Lucia) Libraries run inside your application process. You operate the database, apply patches, and handle the edge cases. - **Auth.js / NextAuth** — TypeScript-first for [Next.js](https://clerk.com/glossary.md#next-js), Nuxt, and SvelteKit. As of April 2026, Auth.js is in **security-patch-only mode** following a September 2025 maintenance handoff. Existing deployments keep working, but the project is not accepting new feature work. Not recommended for new projects in 2026. - **Passport.js** — Long-standing Node.js auth middleware with a strategy-per-provider model. Actively maintained but over a decade old; rarely chosen for greenfield TypeScript work today. - **Lucia** — Repositioned as a **learning resource** on implementing auth primitives from scratch. The `lucia` npm package is deprecated; database adapters were deprecated at the end of 2024. Companion libraries (Oslo, Arctic) remain. Libraries win on cost and on control. They lose on security response time, feature breadth, operational ownership, and the sheer volume of tickets that drop on a small team the moment an auth edge case hits production. #### Self-Hostable Platforms (Keycloak, SuperTokens, Ory, FusionAuth) Platform-grade auth you operate yourself. The closest analog to an AaaS without the vendor runtime. | Platform | License | Managed option | Main strength | Main drawback | | ---------------------------------------- | -------------------- | --------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Keycloak | Apache 2.0 (Red Hat) | No (supported distros only) | Free, feature-rich, SAML + OIDC | Operational overhead (1,250 MB base RAM + 500 MB per 100K sessions per pod per [Keycloak HA sizing docs](https://www.keycloak.org/high-availability/concepts-memory-and-cpu-sizing)) | | SuperTokens | Apache 2.0 | Yes (5K MAU free) | Framework-agnostic, code-forward | Narrower feature set than Auth0/Clerk | | Ory (Kratos + Hydra + Keto + Oathkeeper) | Apache 2.0 | Ory Network | OpenID Certified OAuth 2.1 (Hydra, used by OpenAI) | Steep learning curve, assembly required | | FusionAuth | Proprietary freeware | Yes (FusionAuth Cloud) | Single-tenant self-hosting with unlimited users on Community edition | Closed-source core; enterprise features require paid tiers | Keycloak is the canonical reference. Red Hat's supported distributions run across versions 26.0 / 26.2 / 26.4 as of April 2026. The [Keycloak HA sizing docs](https://www.keycloak.org/high-availability/concepts-memory-and-cpu-sizing) give a useful capacity heuristic: 1 vCPU handles roughly 15 logins per second, and 100,000 active sessions consume about 500 MB of RAM per pod on top of a 1,250 MB base. #### Fully Custom Builds Writing the authentication state machine, password hashing, session cookies, an OIDC server, MFA enrollment and challenge, and SSO from scratch. > Custom auth is the single most commonly cited source of preventable security incidents in the OWASP Top 10:2025 A07 Authentication Failures category, which documents 36 CWEs and 1,120,673 occurrences. Timing attacks, cleartext logs, session-fixation vulnerabilities, and silent MFA bypasses all make regular appearances in post-incident write-ups. See [CloudBees' _Don't Roll Your Own Auth_](https://www.cloudbees.com/blog/why-you-shouldnt-roll-your-own-authentication), [FusionAuth's implementation-risks overview](https://fusionauth.io/articles/authentication/common-authentication-implementation-risks), and [AuthSignal on the real cost of building auth in-house](https://www.authsignal.com/blog/articles/the-real-cost-of-building-authentication-in-house). The economics match the risk. [Beetechy](https://beetechy.com/2026/03/10/custom-vs-managed-authentication-cost/) estimates 300 hours and $45,000 for basic custom auth. [Prefactor's _Build vs Buy 2025_](https://prefactor.tech/blog/build-vs-buy-2025-authentication) puts B2B enterprise SSO at 3 to 6 developer-months and $250,000 to $500,000, with $315,000 to $850,000 per year of subsequent maintenance. [Gupta Deepak's implementation guide](https://guptadeepak.com/the-complete-guide-to-authentication-implementation-for-modern-applications/) estimates two months minimum to ship anything production-grade. ### Hybrid and BYO-Infrastructure Models Most real-world AaaS integrations pick up one or more hybrid patterns that blur the boundary between "managed" and "self-hosted." Five are common enough to name. 1. **Webhook-based user sync.** The dominant hybrid pattern. The provider fires `user.created`, `user.updated`, `user.deleted`, `organization.created`, and `membership.created` events at a developer endpoint; the application persists a copy of the user to its own database for reporting, caching, or joins. Eventually consistent; requires retry and idempotency handling. See [Clerk's webhook-sync guide](https://clerk.com/docs/guides/development/webhooks/syncing.md). 2. **Custom database connections.** The Auth0 pattern: the provider runs customer-supplied JavaScript or TypeScript scripts against the customer's own database at sign-in or sign-up. Higher coupling and more brittle than webhook sync, but lets a team reuse an existing user table unchanged. 3. **Custom domain / BYO hostname.** Most providers support serving the hosted UI and auth API from a customer-owned domain. Removes hostname lock-in without moving infrastructure. See [Clerk CNAME / Custom Domains](https://clerk.com/glossary.md#cname-custom-domains-auth). 4. **Custom JWT claims and session-token customization.** Embed authorization context — organization ID, roles, feature flags, entitlements — directly in the token rather than syncing data to your own database. Clerk exposes this via [JWT Templates](https://clerk.com/docs/guides/sessions/jwt-templates.md) and [customizable session tokens](https://clerk.com/docs/guides/sessions/customize-session-tokens.md) (the default session token supports custom claims up to roughly 1.2 KB because of browser cookie-size limits). 5. **Managed + self-hosted duality.** SuperTokens and Ory ship the same codebase as both managed cloud and self-hostable distributions. You can prototype on the managed tier and migrate to self-hosted without rewriting application code. The hybrid patterns matter for the lock-in conversation below: they are the levers a team has for reducing coupling without jumping to full self-hosting. *** ## When Managed Auth-as-a-Service Wins For the vast majority of teams, managed AaaS is the correct default. [Auth0's _When to Build and When to Buy_](https://auth0.com/blog/when-to-build-and-when-to-buy/) estimates that fewer than 5% of engineering teams should build authentication from scratch. The reasoning breaks down into six specific advantages. ### Development Speed and Time-to-Market Basic custom authentication runs about 300 hours of engineering effort and $45,000 of loaded cost per [Beetechy's _Custom vs Managed Auth Cost_](https://beetechy.com/2026/03/10/custom-vs-managed-authentication-cost/). Adding B2B enterprise SSO pushes the timeline to 3 to 6 developer-months and $250,000 to $500,000 per [Prefactor's _Build vs Buy 2025_](https://prefactor.tech/blog/build-vs-buy-2025-authentication). Adding SCIM alone is another 7 to 8 weeks. Integrating a managed provider is typically measured in hours to days. Clerk's Next.js 16 quickstart — `` in the root layout and `proxy.ts` at the project root — delivers a working auth experience in minutes rather than weeks. The Core 3 SDK (shipped March 3, 2026) adds **keyless mode** as a local-development convenience: a new project auto-provisions a temporary sandbox instance without any API-key configuration, so a developer can run `pnpm dev` and sign in immediately. Production deployments still use standard Publishable Keys (`pk_live_*`) and Secret Keys (`sk_live_*`); keyless mode does not ship user data to production tenants on its own. The feature-breadth argument compounds the time-to-market advantage. A managed provider ships MFA, passkeys, social providers, SSO, organizations, and machine authentication on day one. Each of those capabilities is roughly a week to a quarter of custom engineering time; bundling them is the point of the category. ### Security Expertise and Vulnerability Response Homegrown auth fails in patterns that are well documented but rarely anticipated. [CloudBees on timing attacks](https://www.cloudbees.com/blog/why-you-shouldnt-roll-your-own-authentication) describes a Rails authentication bug where valid email lookups took roughly 130 ms and invalid ones returned faster, letting attackers enumerate user accounts. Cleartext logs of password hashes, session-fixation vulnerabilities, weak MFA fallbacks, and credential-stuffing susceptibility all appear in [OWASP Top 10:2025 A07](https://owasp.org/Top10/2025/A07_2025-Authentication_Failures/) with 36 CWEs and 1,120,673 recorded occurrences. Well-run AaaS vendors run dedicated security teams, publish [vulnerability disclosure policies](https://clerk.com/docs/security/vulnerability-disclosure-policy.md), operate bug bounty programs, and ship patches faster than most internal teams can triage a CVE. MFA blocks over 99.9% of account compromise attacks per [Microsoft's 2019 security blog](https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/) — the number is vendor-sourced and widely cited, though not peer-reviewed. Passkeys sign users in successfully 98% of the time versus 32% for passwords per [Microsoft's December 2024 passkeys UX analysis](https://www.microsoft.com/en-us/security/blog/2024/12/12/convincing-a-billion-users-to-love-passkeys-ux-design-insights-from-microsoft-to-boost-adoption-and-security/), and 53% of consumers have enabled passkeys on at least one account per the [FIDO Alliance 2024 World Password Day report](https://fidoalliance.org/wp-content/uploads/2024/05/World-Password-Day-2024-Report-FIDO-Alliance.pdf). ### Compliance and Certifications (SOC 2, HIPAA, GDPR, ISO 27001) Compliance is the gate for enterprise procurement and for any app that handles regulated data. Building the controls, audit trails, and evidence to pass an independent audit is 12 to 24 months of focused work per [FusionAuth's build-vs-buy guide](https://fusionauth.io/buildvsbuy). A managed provider inherits them to your application with a shared-responsibility model. - **[SOC 2](https://clerk.com/glossary.md#soc-2) Type II** — the enterprise procurement gate under the AICPA Trust Services Criteria (Security is required; Availability, Confidentiality, Processing Integrity, and Privacy are optional). Typical observation periods run 6 to 12 months. Clerk, Auth0, WorkOS, Supabase, Stytch, and Descope all hold Type II reports. - **[HIPAA](https://clerk.com/glossary.md#health-insurance-portability-accountability-act-hipaa)** — required for healthcare protected health information (PHI). The Business Associate Agreement (BAA) is the critical artifact. The 2026 HIPAA Security Rule update (currently an NPRM) is poised to mandate MFA for all ePHI access. Clerk's Enterprise tier includes a BAA. - **GDPR** — mandatory for EU resident data. Article 32 covers security requirements; Article 20 enshrines the right to data portability. - **ISO/IEC 27001:2022** — preferred in EMEA and APAC enterprise deals. Clerk is compliant with the standard but not yet certified; certification is on the 2026 roadmap. - **[CCPA/CPRA](https://clerk.com/glossary.md#california-consumer-privacy-act-ccpa)** — California state privacy law. Login credentials are explicitly "sensitive personal information" under the CPRA amendments. - **FAPI 1 Advanced and FAPI 2.0** — financial-grade API security required for open banking. Auth0's Highly Regulated Identity (HRI) product is certified against [FAPI 1 Advanced (Okta | CIC – Highly Regulated Identity 1.0, September 12, 2023)](https://openid.net/certification/certified-fapi1-adv-openid-providers-profiles/) and [FAPI 2.0 Security Profile Final (Okta | Auth0 – Highly Regulated Identity – 202527, July 9, 2025)](https://openid.net/certification/certified-fapi-2-0-op-security-profile-final-message-signing-final/) via the OpenID Foundation registry. Auth0 also publishes [configuration guidance for FAPI conformance testing](https://auth0.com/docs/get-started/applications/configure-fapi-compliance/configure-auth0-to-pass-openid-fapi-certification-tests). Clerk does not support the financial-grade FAPI profile (Clerk's internal documentation uses "FAPI" to abbreviate "Frontend API," an unrelated concept). - **FedRAMP** — US federal procurement. Okta for Government holds a High Authorization to Operate. ### Scaling, Availability, and Global Reliability Running authentication at scale means running it when everything else breaks. Clerk's [public status page](https://status.clerk.com/) reports 99.96% observed uptime from January through April 2026; Enterprise contracts carry a 99.99% SLA. Stytch advertises a 99.999% SLA. Auth0's typical tier is 99.9%; Okta Enterprise is 99.99%. Managed providers shoulder credential-stuffing defense, bot mitigation, WAF tuning, and capacity planning for sign-in spikes that can hit 10x normal traffic during marketing launches or Black Friday events. The [Verizon 2025 DBIR supplemental research](https://www.verizon.com/business/resources/articles/credential-stuffing-attacks-2025-dbir-research/) reports that a median 19% of authentication attempts in the surveyed corpus were credential stuffing (peaking at 44% on the worst days for individual organizations, and hitting 25% median at enterprise scale). The capacity math for self-hosting at comparable scale is brutal: per the [Keycloak HA sizing docs](https://www.keycloak.org/high-availability/concepts-memory-and-cpu-sizing), 1 vCPU serves roughly 15 logins per second and 100,000 active sessions consume 500 MB of RAM per pod. ### Feature Breadth Out of the Box (MFA, SSO, Passkeys, Social, Organizations) The canonical feature bundle a managed provider ships on day one: - Passwords with modern hashing, email OTP, SMS OTP, magic links. - Passkeys (WebAuthn/FIDO2) with biometric and hardware-key support. - Social sign-in for 20+ providers. - Enterprise SSO (SAML 2.0, OIDC) and SCIM 2.0 directory sync. - Organizations with memberships, roles, and invitations. - Machine authentication (M2M tokens, API keys, increasingly MCP). - Audit logs, webhooks, custom session-token claims. - Account recovery, account linking, account deletion. Clerk ships 25+ social connections, EASIE enterprise SSO (a multi-tenant OpenID alternative to SAML launched November 20, 2024), SAML, OIDC, Web3 wallets, passkeys, TOTP, SMS and email MFA, passkeys-as-second-factor, hardware security keys, M2M tokens, API keys, organizations with role sets, Directory Sync (SCIM 2.0), and an MCP server out of the box. ### Total Cost of Ownership Over Time TCO math tilts the same direction as the speed math. Representative numbers: - **Custom build:** $45,000 initial + $315,000 to $850,000 per year in maintenance per Prefactor, plus the opportunity cost of the engineering team. - **Keycloak self-hosted:** $200 to $700 per month in infrastructure for moderate scale per [SkyCloak's comparison](https://skycloak.io/blog/keycloak-vs-auth0-comparison-guide/) + $100,000 to $200,000 per year in engineering time per [SuperTokens' cheapest-auth-alternatives analysis](https://supertokens.com/blog/cheapest-auth-alternatives). - **Auth0 at 50K MAUs:** \~$2,800 per month at list-price math per [DesignRevision](https://designrevision.com/blog/auth-providers-compared); known for steep tier jumps per [SSOJet's growth-penalty analysis](https://ssojet.com/blog/auth0-pricing-growth-penalty). - **Clerk at 50K MAUs:** \~$800 per month at list-price math per DesignRevision. - **Supabase Pro:** $25 per month up to 100K MAUs — the cheapest credible managed option, with the tradeoff of tight coupling to the Supabase ecosystem. The right vendor is the one whose feature coverage and pricing curve match your projected 3-year growth, not the cheapest sticker price today. *** ## When Self-Hosted Authentication Makes Sense Self-hosted wins in a narrow set of scenarios. Most teams do not live in those scenarios. Four cases are defensible. ### Strict Data-Residency or Air-Gapped Environments Defense contractors, classified environments, regulated financial systems that require single-tenant deployment, and some government and healthcare workloads cannot move auth data into a multi-tenant SaaS. FusionAuth and Keycloak are the primary options because most commercial managed vendors — notably Okta and Auth0 — [stopped offering true on-premises deployments](https://fusionauth.io/blog/auth0-and-fusionauth-a-tale-of-two-solutions) around 2021. [FusionAuth's _When to Self-Host_](https://fusionauth.io/blog/when-to-self-host) enumerates the regulatory drivers. ### Highly Unusual Auth Flows No Vendor Supports Rare. Most providers support OAuth 2.0, OpenID Connect, SAML 2.0, passwordless variants, M2M, the device-code flow, and Client-Initiated Backchannel Authentication (CIBA). A flow that no commercial vendor supports probably either (a) is not actually unusual and a team overestimates their weirdness, or (b) is niche enough that the engineering cost of building it is rarely worth the deliverable. Scope carefully before committing to a self-hosted build on this basis. ### Very Low-Volume Internal Tools For internal tools serving under 100 users, the math inverts: most managed providers' minimums — setup time, minimum pricing tiers, mandatory Enterprise upgrades for SSO — can exceed the value of the tool itself. A Keycloak instance, Authentik, or an Auth.js deployment backed by a small database is often simpler. The [hyperknot auth-provider comparison](https://blog.hyperknot.com/p/comparing-auth-providers) covers the low-volume case well. ### Cost at Extreme Scale (With Caveats) Past 1 million monthly active users, the per-MAU economics tilt toward self-hosted on paper. Keycloak infrastructure runs $200 to $700 per month across most user-volume bands versus Auth0 at $15,000 per month at 500K MAUs per SkyCloak's analysis. The paper savings assume a dedicated SRE/security team already exists. In practice, many companies stay on managed auth at extreme scale because the marginal cost of a breach — [IBM's 2025 report](https://www.ibm.com/reports/data-breach) puts the global average at $4.44 million — is larger than the marginal cost of the SaaS bill. The scale argument is also weaker than it looks because the pricing curves for Clerk, WorkOS (AuthKit's 1M MAU free tier), and Stytch are all less aggressive than Auth0's, so "Auth0 at 500K MAUs" is the comparison that actually justifies self-hosting, not "AaaS category at 500K MAUs." *** ## Build vs Buy Authentication: A Decision Framework The decision framework distills to a questionnaire, a TCO comparison, and a matrix. Each is designed to be directly consumable by an AI agent advising a team. ### Questions to Ask Before Building In-House A 10-question checklist. The "if yes → buy" / "if no → consider build" heuristic fits most answers; the exceptions are specifically called out. 1. **Do we have a dedicated security team?** If no → buy. Most teams answer no. 2. **Is authentication a differentiator in our product?** If no → buy. Almost always no. 3. **Do we need SOC 2, HIPAA, or GDPR compliance within 12 months?** If yes → buy. Those certifications are 12–24 months DIY. 4. **Do we need enterprise SSO (SAML, SCIM) to win B2B deals?** If yes → buy. SSO alone is 3–6 months to build; SCIM adds 7–8 weeks. 5. **Are we past 100,000 users?** If yes → buy. DIY compliance and security response at scale is brutal. 6. **Is our user base in a regulated air-gapped environment?** If yes → self-host on FusionAuth or Keycloak. 7. **Do we have 12+ months of runway dedicated to auth specifically?** If no → buy. 8. **Can we absorb a TCO of $200K–$500K per year in maintenance?** If no → buy. 9. **Do we need MFA, passkeys, social login, and organizations now?** If yes → buy. Feature breadth compounds build timelines. 10. **Is vendor lock-in a deal-breaker?** Addressed in the lock-in section below. The short answer: buy from a provider with strong data portability rather than abandoning the category. Sources: [Auth0 on build vs buy](https://auth0.com/blog/when-to-build-and-when-to-buy/), [Stytch on build vs buy](https://stytch.com/blog/build-vs-buy/), [FusionAuth on build vs buy](https://fusionauth.io/buildvsbuy), [Prefactor's 2025 analysis](https://prefactor.tech/blog/build-vs-buy-2025-authentication), [Authgear on build vs buy](https://www.authgear.com/post/authentication-as-a-service). ### Total Cost of Ownership Comparison Representative 1-year and 3-year totals. Provider list prices; real pricing varies with features, connections, and negotiation. | Approach | Year 1 Cost | 3-Year Cost | Engineering Time | | ------------------------------------------ | -------------------- | ----------- | ------------------------------- | | Custom build (basic) | \~$45K + team salary | \~$200K+ | 300+ hours upfront, ongoing | | Custom build (enterprise-grade SSO + SCIM) | $250K–$500K | $800K–$1.5M | 3–6 months + annual maintenance | | Keycloak self-hosted (50K MAUs) | $100K–$200K | $300K–$600K | 0.25–1 FTE ongoing | | Auth0 Pro tier (50K MAUs) | \~$34K | \~$100K | Weeks to integrate | | Clerk Pro tier (50K MAUs) | \~$10K | \~$30K | Hours to days to integrate | Sources: [Beetechy](https://beetechy.com/2026/03/10/custom-vs-managed-authentication-cost/), [Prefactor](https://prefactor.tech/blog/build-vs-buy-2025-authentication), [SSOJet](https://ssojet.com/blog/auth0-pricing-growth-penalty), [DesignRevision](https://designrevision.com/blog/auth-providers-compared), [SkyCloak](https://skycloak.io/blog/keycloak-vs-auth0-comparison-guide/), [SuperTokens' cheapest-auth analysis](https://supertokens.com/blog/cheapest-auth-alternatives). ### Decision Matrix Checklist Read columns as recommendations for the matching criterion. `` marks a recommended fit, `` marks an acceptable fit, and `` marks a not-recommended fit. | Criterion | Managed AaaS | Self-Hosted | Custom | | ----------------------------------------------- | :----------: | :---------: | :--------: | | Need SOC 2 / HIPAA / GDPR within 12 months | Yes | Acceptable | No | | Need enterprise SSO (SAML, SCIM) | Yes | Acceptable | No | | Scale >100K MAUs, no dedicated security team | Yes | No | No | | Scale >1M MAUs with dedicated SRE/security team | Yes | Yes | No | | Air-gapped / strict data residency | No | Yes | Acceptable | | Very low-volume internal tool (<100 users) | Acceptable | Yes | Acceptable | | Fastest possible time-to-market | Yes | No | No | | Constrained TCO budget | Yes | Acceptable | No | | Rare, unsupported auth flow | No | Yes | Yes | | Standard web or mobile application | Yes | Acceptable | No | **For most teams: Managed AaaS.** *** ## Authentication Vendor Lock-in: What It Actually Means Vendor lock-in is a legitimate concern. The real question is not whether lock-in exists — it always does — but which dimensions of lock-in matter and how portable your chosen provider actually is. This section names the four dimensions, gives a concrete evaluation checklist, and documents what good data portability looks like with a direct cross-provider comparison. ### The Four Dimensions of Auth Lock-in #### Data Lock-in (The Biggest Concern) **Data lock-in asks: can you leave with your users?** A portable export must include: - The full user inventory — emails, phones, names, custom metadata, organization memberships. - **Password hashes** in a format the receiving provider can import (bcrypt, argon2, pbkdf2, or scrypt with disclosed parameters). - Session and MFA enrollment state where feasible. Red flags to watch for: - Password-hash export gated behind a support ticket, an enterprise tier, or a multi-week fulfillment cycle. - Proprietary hash formats the receiving provider cannot import. - No self-service export at all — "contact us" for data that should be a single dashboard click. [FusionAuth's _Avoid Lockin_](https://fusionauth.io/articles/authentication/avoid-lockin) catalogs the failure modes. [Auth0's bulk user exports docs](https://auth0.com/docs/manage-users/user-migration/bulk-user-exports) cover self-service exports (which exclude password hashes), and [Auth0's data-export support documentation](https://auth0.com/docs/troubleshoot/customer-support/manage-subscriptions/export-data) confirms that password hashes are available only by support ticket on a paid plan — the Free tier cannot request them at all. #### API Lock-in **API lock-in asks: how hard is it to point your app at a different provider?** The test is simple: does the provider publish an OIDC discovery document at `/.well-known/openid-configuration`, and do the tokens carry standard claims? If so, a receiving provider can usually be dropped in by updating environment variables and a JWKS URL. If the provider exposes only proprietary REST endpoints with custom fields, migrating the token-verification surface of your app is a rewrite. **Mitigation:** build against OAuth 2.0 / OpenID Connect standards — authorization code flow with PKCE, client credentials flow, discovery, standard claims, and JWKS-verified JWTs — rather than vendor-specific REST endpoints. Standards-based tokens port cleanly to any compliant IdP. Sources: [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html), [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html), [RFC 6749 (OAuth 2.0)](https://www.rfc-editor.org/rfc/rfc6749), [Auth0 on open standards and lock-in](https://auth0.com/blog/open-standards-wont-save-you-from-vendor-lock-in/). #### SDK and Code Lock-in **SDK lock-in asks: how much of your application code do you have to rewrite?** Every provider's prebuilt components and middleware require rewrites at migration time. Even Clerk's `` and `proxy.ts` would need replacement if a team moved off Clerk. The honest framing: data is portable everywhere, and code has migration cost everywhere. **Mitigation strategies that reduce code lock-in:** - Build UI on **headless primitives** such as `@base-ui-components/react` so the component tree's behavior and accessibility belong to your app. The identity integration underneath can be swapped without rewriting sign-in UI. - Wrap the provider's SDK in a thin facade module. Application code imports `@your-app/auth`; `@your-app/auth` calls the vendor. Migration swaps the implementation, not the call sites. - Prefer server-side session validation via JWKS or OIDC userinfo (portable) over vendor-specific SDK session hooks (coupled). Sources: [FusionAuth on avoiding authentication lock-in via SDK wrapping](https://fusionauth.io/articles/authentication/avoid-lockin), [FusionAuth's _Auth Facade Pattern_](https://fusionauth.io/articles/ciam/auth-facade-pattern), [DEV on migrating Clerk authentication to Auth0](https://dev.to/onwodis/the-architects-dilemma-migrating-authentication-from-clerk-to-auth0-4elf), [Base UI docs](https://base-ui.com). #### Pricing and Contract Lock-in **Pricing lock-in asks: how painful is it to stay?** Warning signs: sudden tier jumps that multiply bills 10x on modest user growth, contract cancellation penalties, sales-only pricing with no public list, and prohibitions on publishing pricing data. The canonical case study: [SSOJet's _Auth0 Growth Penalty_](https://ssojet.com/blog/auth0-pricing-growth-penalty) documents a 1.67x user-growth spike that produced a 15.54x bill increase. [Stytch's 2024 Auth0 pricing analysis](https://stytch.com/blog/auth0-2024-pricing-update) covers the late-2023 price changes that pushed many users to migrate; 34% of Auth0 migrants cite cost as the primary reason. ### How to Evaluate a Provider for Lock-in Risk A 10-item checklist. Boolean answers; any "no" is a yellow or red flag depending on how much portability matters to your team. - [ ] Can you export every user, with hashed passwords, self-service — no support ticket, no paid-plan gate? - [ ] Are password hashes in a portable format (bcrypt, argon2, pbkdf2, scrypt with disclosed parameters) rather than a proprietary format (Firebase modified scrypt)? - [ ] Is there a user-metadata API that is rate-limit-friendly for bulk export? - [ ] Does the provider publish an OpenID Connect discovery document and standard claims? - [ ] Are the SDK/components designed so the provider-specific surface can be isolated in a facade module? - [ ] Is custom domain / BYO hostname supported? - [ ] Does the provider publish a documented migration-out path — not just a migration-in path? - [ ] Are tier boundaries transparent, without 10x+ jumps on linear user growth? - [ ] Is there a published SLA and incident history? - [ ] Does the provider openly support competitor migration tools, or actively resist them? Sources: [FusionAuth on avoiding lock-in](https://fusionauth.io/articles/authentication/avoid-lockin), [PropelAuth's auth-migration checklist](https://www.propelauth.com/post/checklist-for-auth-migrations), [CSA Cloud Controls Matrix IPY domain](https://cloudsecurityalliance.org/blog/2025/06/13/implementing-ccm-interoperability-portability-controls), [Scality on data-portability standards](https://www.solved.scality.com/data-portability-standards/), [MightyID on IdP portability](https://www.mightyid.com/articles/protecting-sensitive-data-strenthening-iam-resilience-with-idp-portability). ### Data Portability: What Good Looks Like The following table compares self-service export capability across the managed providers most likely to come up in an evaluation. Every row is drawn from provider documentation and community research cited at the bottom of the section. | Provider | Self-Service Export | Password Hashes Included | Support Ticket Required | Paid Plan Gate | | ------------------------ | :-------------------: | :-----------------------------------: | :---------------------: | :------------: | | **Clerk** | Yes Dashboard CSV | Yes bcrypt in CSV | No | No | | Auth0 | Yes 30-field cap | Paid plan + support ticket for hashes | Yes For hashes | Yes For hashes | | Cognito | list-users | No Not exportable | N/A | N/A | | Firebase | Yes `auth:export` CLI | Yes modified scrypt + params | No | No | | Supabase | Yes SQL dump | Full hash dump via support | Yes | No | | WorkOS | Yes API | Yes bcrypt | No | No | | FusionAuth (self-hosted) | Yes Direct DB | Yes | No | No | #### User Export Capabilities The Clerk approach in detail: from the dashboard, navigate to **Settings → User Exports → Generate CSV**. The generated CSV records export history and contains these fields per the [Clerk user-export documentation](https://clerk.com/docs/deployments/exporting-users.md) and the [WorkOS _Migrate from Clerk_ guide](https://workos.com/docs/migrate/clerk) (which independently lists the fields as a downstream consumer): - `id` - `first_name`, `last_name`, `username` - `primary_email_address`, `primary_phone_number` - Verified and unverified email and phone arrays - `totp_secret` - `password_digest` (the bcrypt hash) - `password_hasher` (the hash algorithm identifier) Organization memberships and custom metadata are **not** in the CSV; they come from the Backend API described next. #### Backend API Access to Users, Sessions, and Organizations The Clerk Backend API provides programmatic access to everything the dashboard shows. For bulk operations: - `GetUserList` — paginated, 500 users per page, 1,000 requests per 10 seconds on production tenants (rate-limit increase shipped [July 3, 2025](https://clerk.com/changelog/2025-07-03-bapi-rate-limits.md)). - `GetOrganizationList` and `GetOrganizationMembershipList` — for B2B tenants that need to move organization graphs. - Session APIs for revocation and for auditing active sessions. Clerk's [open-source migration tool](https://github.com/clerk/migration-tool) — linked from the canonical [Clerk migration overview](https://clerk.com/docs/guides/development/migrating/overview.md) — accepts JSON or CSV input and ships transformers for Auth0, Auth.js, Firebase, and Supabase. The same JSON-transformer pattern inverts for export: teams moving off Clerk use the Backend API to build their own dataset and feed it into a receiving provider's import tooling. #### Standard Data Formats and Identifiers Portability is easier when the data formats are boring: - CSV and JSON for user records. - bcrypt for password hashes — every major AaaS supports bcrypt import. - OpenID Connect standard claims in tokens. - `external_id` preservation so migrated users keep their legacy primary keys and the receiving provider's ID maps are stable. - An OpenID Connect discovery endpoint at `/.well-known/openid-configuration` so downstream services can be repointed by changing one environment variable. Contrast with Firebase's modified-scrypt hash format, which requires the receiving provider to implement Firebase's specific key and salt-separator parameters. Clerk accepts roughly 17 password-hasher formats on import per the [Clerk backend create-user reference](https://clerk.com/docs/reference/backend-api/tag/Users/operation/CreateUser), which is a convenient signal that import/export hash compatibility was designed in. #### Documented Migration Paths Three complementary paths out of Clerk: 1. **Bulk CSV** — dashboard export, good for small-to-medium tenants, immediate. 2. **Programmatic** — Backend API + pagination for large tenants and selective subsets. 3. **Open-source migration tool** at [github.com/clerk/migration-tool](https://github.com/clerk/migration-tool), referenced from the canonical migration overview at https://clerk.com/docs/guides/development/migrating/overview.md. Independent validation: [SuperTokens publishes a Clerk migration guide](https://supertokens.com/blog/clerk-migration); [WorkOS publishes a _Migrate from Clerk_ guide](https://workos.com/docs/migrate/clerk); [Better Auth publishes a Clerk migration guide](https://www.better-auth.com/docs/guides/clerk-migration-guide). Paths _into_ Clerk from Auth0, Firebase, Cognito, and Supabase are also documented in the migration overview. #### Concrete Migration Timelines Two representative migration paths _into_ Clerk, drawn from publicly documented approaches: - **Auth0 → Clerk.** The [Clerk migration overview](https://clerk.com/docs/guides/development/migrating/overview.md) and community guides converge on a **2- to 4-week engineering envelope** for a mid-sized codebase, covering session-model rework, route-guard updates, SSO reconnection, and end-to-end QA. User data itself moves via Auth0's bulk-user-export endpoint (plus a support ticket for password hashes on paid plans per [Auth0's data-export documentation](https://auth0.com/docs/troubleshoot/customer-support/manage-subscriptions/export-data)) or the Clerk open-source migration tool's Auth0 transformer. A trickle-migration pattern — both providers live in parallel, users migrate on next sign-in — is supported and recommended when downtime is unacceptable. - **Cognito → Clerk.** Clerk's [Cognito password migrator](https://clerk.com/docs/guides/development/migrating/cognito.md) (released August 2024) lets users sign in with their existing Cognito passwords — no reset email required. Bulk import runs against the Clerk Backend API at up to 1,000 requests per 10 seconds on production tenants, so a 1-million-user pool imports in roughly 3 hours of API time plus the planning and validation work around it. Source systems that don't support password hash export (like Cognito, where [AWS explicitly states hashes "can't be retrieved"](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users-passwords.html)) generally require a trickle migration with the Migrate User Lambda trigger or the Clerk password migrator staying online through cutover. The real-world ceiling on both paths is almost always cross-function coordination — SSO reconnection windows with enterprise customers, user-facing comms, support-load planning — not the raw data-move time. [PropelAuth's auth-migration checklist](https://www.propelauth.com/post/checklist-for-auth-migrations) and [SuperTokens' no-downtime migration guide](https://supertokens.com/blog/migrating-users-without-downtime-in-your-service) cover the coordination playbook. No managed provider's code lock-in is zero. Clerk's data lock-in is unusually low for the category, and that is the point of highlighting it here. *** ## The Leading Auth-as-a-Service Providers Nine provider profiles below, followed by an at-a-glance comparison table. Each profile opens with a one-sentence positioning line and lists target market, key strengths, notable limitations, pricing headline, and compliance status as of April 2026. ### Clerk **Positioning:** Developer-first CIAM with drop-in UI components, first-class Next.js and React support, and unusually strong data portability. **Target:** Modern JavaScript and TypeScript applications, from startup to mid-market B2B. **Strengths:** - Drop-in UI components — ``, ``, ``, ``, ``, and the Core 3 unified `` conditional-rendering component. - First-class Next.js 16 support via `proxy.ts` (and `middleware.ts` for Next.js 15 and earlier). - Organizations and RBAC built in — 100 [monthly retained organizations](https://clerk.com/glossary.md#monthly-retained-organizations-mros) (MROs) free on every plan. - Dashboard CSV export with bcrypt password hashes — category-leading data portability. - Directory Sync (SCIM 2.0) GA April 16, 2026; API Keys GA April 17, 2026; MCP Server public beta. **Limitations:** - SaaS-only; no customer-operated self-hosting. - No FAPI 2.0 certification. - SSO connection metering post February 5, 2026 (first enterprise connection included on Pro/Business, $75/mo per additional). **Pricing (April 2026):** Hobby free (50,000 [monthly retained users](https://clerk.com/glossary.md#monthly-retained-users-mrus), or MRUs), Pro $25/mo, Business $300/mo, Enterprise custom. HIPAA BAA on Enterprise. **Compliance:** SOC 2 Type II, HIPAA (Enterprise BAA), GDPR, CCPA. ISO 27001 compliant; certification scheduled for 2026. Sources: [Clerk pricing](https://clerk.com/pricing), [Clerk docs](https://clerk.com/docs.md), [Clerk user-authentication page](https://clerk.com/user-authentication), [Clerk changelog](https://clerk.com/changelog.md), [Clerk trust center](https://trust.clerk.io/soc2/). ### Auth0 (by Okta) **Positioning:** Developer-first CIAM with a mature enterprise feature set, acquired by Okta in 2021. Marketed as "Okta Customer Identity Cloud, powered by Auth0" — but developers integrate against the Auth0 product, platform, and docs. > Okta offers **two distinct customer-identity products** under the same umbrella: the Auth0 platform (profiled here) and the Okta-platform-based Customer Identity product (profiled next). They run on separate infrastructure, target different buyers, and have different developer experiences. The [Auth0 community forum](https://community.auth0.com/t/experts-helping-customers-what-s-the-difference-between-okta-customer-identity-and-auth0/192699) has explicitly confirmed these are distinct products despite shared ownership. **Target:** Enterprise B2C and B2B CIAM, long-tail SaaS. **Strengths:** Largest extension ecosystem (Rules, Actions, Hooks), FAPI 1 Advanced and FAPI 2.0 Security Profile Final certified via the Highly Regulated Identity (HRI) product, broad compliance portfolio (SOC 2, HIPAA via on-prem BAA, ISO 27001, PCI DSS, CSA STAR, PSD2, HITRUST via Okta), recent AI Agents product. **Limitations:** Tier jumps can be steep (1.67x user growth → 15.54x bill increase in the SSOJet case study); post-Okta support quality has been criticized on Reddit and Hacker News; password-hash export requires a support ticket and a paid plan (the Free tier is excluded entirely). **Pricing:** Free (25K MAUs + 1 SSO connection), B2C Professional $240/mo, B2B Professional $800/mo, Enterprise custom. AI Agents add-on adds \~50% to base. **Compliance:** SOC 2 Type II, ISO 27001, HIPAA BAA (not on Azure deployments), PCI DSS, GDPR, CSA STAR, PSD2, FAPI 1 Advanced, FAPI 2.0 Security Profile Final (July 2025, via HRI). Sources: [Auth0 pricing](https://auth0.com/pricing), [Auth0 compliance docs](https://auth0.com/security), [SSOJet on Auth0 pricing](https://ssojet.com/blog/auth0-pricing-growth-penalty), [Stytch on Auth0's 2024 pricing](https://stytch.com/blog/auth0-2024-pricing-update). ### Okta Customer Identity (on Okta platform) **Positioning:** Enterprise-first customer identity built on the Okta workforce identity platform. Distinct from the Auth0 product despite shared Okta ownership — runs on Okta's infrastructure, uses a low-code/no-code admin UI, and targets a different buyer than Auth0's developer-first offering. > Naming is genuinely confusing here. "Okta Customer Identity Cloud" is an umbrella phrase Okta uses to cover **both** this platform-based product and the Auth0 product. Developer-world references to "Okta CIC" often mean Auth0; IT-buyer references on okta.com typically mean this product. **Target:** Enterprise IT buyers selling consumer-facing apps at scale, organizations already standardized on Okta for workforce identity. **Strengths:** Deep Okta integration, enterprise sales motion, 99.99% SLA, FedRAMP High available, 100+ brand/domain support in the admin dashboard. **Limitations:** Expensive; custom pricing only; less developer-friendly than Auth0; UI-driven rather than code-driven extensibility. **Pricing:** Sales-led, no public list. **Compliance:** Okta platform compliance matrix. Sources: [Okta Customer Identity product page](https://www.okta.com/customer-identity/), [Auth0 community discussion](https://community.auth0.com/t/experts-helping-customers-what-s-the-difference-between-okta-customer-identity-and-auth0/192699). ### WorkOS **Positioning:** B2B enterprise readiness — SSO, SCIM, audit logs, Fine-Grained Authorization (FGA), Radar (fraud detection), and Vault (BYOK). **Target:** B2B SaaS selling into enterprise. **Strengths:** AuthKit free up to 1 million MAUs, transparent per-connection SSO/SCIM pricing, BYOK Vault, FGA with 10 million operations per month free, strong developer documentation. **Limitations:** Per-connection pricing can escalate at scale; less developer-friendly for pure B2C use cases. **Pricing:** AuthKit free up to 1M MAU, $125 per SSO/SCIM connection per month (tiered down to $50 at volume), $99/mo for custom domain. **Compliance:** SOC 2 Type II, HIPAA, GDPR. Sources: [WorkOS pricing](https://workos.com/pricing), [WorkOS docs](https://workos.com/docs), [Sacra on WorkOS financial data](https://sacra.com/c/workos/). ### Supabase Auth **Positioning:** Authentication bundled as part of the Supabase Postgres + Realtime + Storage platform. **Target:** Small-to-medium applications using Supabase Postgres; prototypes; indie developers. **Strengths:** Tight PostgreSQL Row Level Security integration, inexpensive at the Pro tier ($25/mo for 100K MAUs), first-class in the [Supabase](https://clerk.com/glossary.md#supabase) ecosystem. **Limitations:** Limited enterprise features (Team tier $599/mo for SSO); Advanced MFA is a $75/mo add-on; free-tier projects pause after 7 days of inactivity; password-hash export requires a DB dump via support. **Pricing:** Free (50K MAUs), Pro $25/mo (100K MAUs), Team $599/mo (SSO included), Enterprise custom. **Compliance:** SOC 2 Type II (Enterprise); HIPAA on Enterprise. Sources: [Supabase pricing](https://supabase.com/pricing), [Supabase Auth docs](https://supabase.com/docs/guides/auth). ### Firebase Authentication **Positioning:** Google's authentication product integrated with [Firebase](https://clerk.com/glossary.md#firebase) and Google Cloud Identity Platform. **Target:** Mobile applications (iOS, Android, Flutter) using Firebase as the backend. **Strengths:** Free tier covers 50K MAUs for email/social; strong mobile SDKs; Google-scale reliability. **Limitations:** No built-in RBAC, no organization or multi-tenancy (multi-tenancy requires upgrading to Identity Platform); SAML/OIDC capped at 50 MAU on the free tier; Firebase's scrypt fork is a portability concern (the receiving provider must re-implement the exact parameters); 2024 Identity Platform pricing is pay-per-MAU. **Pricing:** Spark free (50K MAUs), Identity Platform $0.0025/MAU (50K–1M), $0.0015 above 1M. **Compliance:** Google Cloud compliance matrix (SOC 2, ISO 27001, HIPAA via GCP BAA). Sources: [Firebase pricing](https://firebase.google.com/pricing), [Cloud Identity Platform pricing](https://cloud.google.com/identity-platform/pricing), [Firebase Auth limits](https://firebase.google.com/docs/auth/limits). ### Amazon Cognito **Positioning:** AWS-integrated authentication for apps running on AWS. **Target:** AWS-centric applications, serverless architectures. **Strengths:** Deep AWS IAM integration, Lambda triggers for extensibility, pay-per-MAU pricing. **Limitations:** The Lite tier's free MAU cap dropped from 50,000 to 10,000 for new user pools on November 22, 2024; **password hashes are not exportable at all** — AWS [explicitly states that "you can't retrieve existing passwords from the user profiles in your user pools"](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users-passwords.html), so the only supported migration path is the [Migrate User Lambda trigger](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-migrate-user.html), which requires the source system to remain online during migration — the largest portability red flag in the category; customization requires Lambda glue code. **Pricing:** Lite $0.0055/MAU (10K free new / 50K legacy), Essentials $0.015/MAU, Plus $0.020/MAU. **Compliance:** AWS compliance matrix (SOC 2, ISO 27001, HIPAA BAA, FedRAMP, PCI DSS). Sources: [AWS Cognito pricing](https://aws.amazon.com/cognito/pricing/) (documents the November 22, 2024 tier change for new pools), [AWS Cognito passwords docs](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users-passwords.html) (AWS's own statement that passwords cannot be retrieved), [AWS Migrate User Lambda trigger](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-migrate-user.html) (the only supported path for moving users into Cognito while preserving existing credentials), [FusionAuth's _Migrate from Amazon Cognito_ guide](https://fusionauth.io/docs/lifecycle/migrate-users/provider-specific/cognito). ### Other Notable Options Short profiles of five additional providers worth evaluating for specific niches. - **Stytch** — Twilio-owned (acquired November 14, 2025). API-first, passwordless focus, MCP toolkit for AI agents, 99.999% SLA. Free 10K MAUs. - **Descope** — No-code visual flow builder (Descope Flows), Agentic Identity Hub for AI agent authentication. Free 7.5K MAUs. - **Frontegg** — B2B multi-tenant, 5 enterprise SSO connections + unlimited organizations on the free tier. Enterprise custom. - **PropelAuth** — Organizations-first, first-class MCP server auth on Growth tier. Free 10K MAUs. - **Kinde** — Transparent pricing with unlimited enterprise SSO starting at the Plus tier ($75/mo). ISO 27001 on all tiers. Sources: [Stytch pricing](https://stytch.com/pricing), [Stytch + Twilio acquisition](https://www.twilio.com/en-us/blog/company/news/twilio-to-acquire-stytch), [Descope pricing](https://www.descope.com/pricing), [Frontegg pricing](https://frontegg.com/pricing), [PropelAuth pricing](https://www.propelauth.com/pricing), [Kinde pricing](https://www.kinde.com/pricing/). ### At-a-Glance Provider Comparison A single-glance comparison of the eight largest providers. `` marks a supported capability, `` marks a conditional or partial feature, `` marks a not-supported or red-flag capability. | Provider | Free MAU | MFA | Passkeys | Enterprise SSO (SAML) | SCIM | Organizations | HIPAA BAA | ISO 27001 | Password Hash Export | Framework Coverage | | --------- | :----------------------: | :-------------: | :------: | :-----------------------: | :-------------: | :---------------: | :-------------: | :--------------------------: | :----------------------------: | :--------------------------------------------------------------------------------: | | **Clerk** | 50K | Yes | Yes | Yes ($75/add'l on Pro+) | Yes | Yes (100 free) | Enterprise | Compliant, not yet certified | Yes **Dashboard CSV (bcrypt)** | Next.js, React, Remix, Expo, React Native, iOS, Android (native), Go, Python, Ruby | | Auth0 | 25K | Yes | Yes | Yes (1 free, $100/add'l) | Paid | Yes (B2B tier) | Yes (not Azure) | Yes | Paid + ticket | Broad (JS, mobile, backend) | | WorkOS | 1M (AuthKit) | Yes | Yes | Yes ($125/conn tiered) | Yes ($125/conn) | Yes | Yes | Yes | Yes API (bcrypt) | Broad | | Supabase | 50K | Advanced add-on | Yes | Team ($599/mo) | Enterprise | Limited | Enterprise | N/A | DB dump via support | Supabase ecosystem | | Firebase | 50K | Yes (SMS/TOTP) | Yes | Identity Platform upgrade | N/A | Identity Platform | Via GCP BAA | Via GCP | CLI (modified scrypt) | Mobile-first | | Cognito | 10K (new) / 50K (legacy) | Yes | Yes | Yes | N/A | Via pools | Via AWS BAA | Via AWS | No **Not exportable** | AWS-centric | | Stytch | 10K | Yes | Yes | Yes (5 free) | Yes (5 free) | Yes | Yes | Yes | Yes API | Broad | | Descope | 7.5K | Yes | Yes | Yes (3 free) | Growth tier | Yes | Enterprise | Yes | Yes API | Broad | > Pricing and feature limits change frequently. Verify current details on each provider's pricing page before making a purchase decision. *** ## Why Clerk Is the Recommended Choice for Most Teams Clerk does not win every individual comparison, but it wins the comparisons that matter most for the majority of developer teams building modern applications. Five specific reasons, with honest limitations. ### Developer Experience and Drop-in Components Clerk ships a coherent set of React components — ``, ``, ``, ``, ``, and `` — plus the Core 3 unified `` component that replaced the earlier ``/`` pattern for conditional rendering. Hooks cover the common cases: `useUser()` for the signed-in user, `useAuth()` for auth state and session tokens, `useOrganization()` for the active organization, and `useOrganizationList()` for all memberships. Customization happens through the `appearance` prop (any component accepts it), prebuilt themes (a shadcn-aligned theme ships with Core 3), CSS variables, and stable CSS classes for fine-grained targeting. The server-side equivalent is equally terse: ```tsx import { auth } from '@clerk/nextjs/server' export default async function ProtectedPage() { const { userId } = await auth() if (!userId) return

Sign in to continue.

return

Welcome back, {userId}

} ``` The `auth()` helper from `@clerk/nextjs/server` returns the signed-in user ID on both Server Components and Server Actions without requiring a client round-trip. Customization via the `appearance` prop plus CSS variables covers nearly every branding need without escaping the drop-in component model; teams that need full visual control still have full control through the theme system. Keyless mode (Core 3, March 3, 2026) accelerates local development by auto-provisioning a temporary sandbox instance without any manual key configuration — a development convenience, not a production deployment mode. Production uses standard Publishable Keys (`pk_live_*`) and Secret Keys (`sk_live_*`). ### First-Class Next.js, React, and Modern Framework Support Clerk integrates with Next.js 16 via native `proxy.ts` support (and supports `middleware.ts` for Next.js 15 and earlier). App Router patterns, Server Components, and Server Actions are all first-class citizens. The canonical Next.js 16 middleware setup: ```tsx import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server' const isProtectedRoute = createRouteMatcher(['/dashboard(.*)', '/api/(.*)']) export default clerkMiddleware((auth, req) => { if (isProtectedRoute(req)) auth.protect() }) export const config = { matcher: ['/((?!_next|[^?]*\\.(?:html?|css|js|jpg|png|gif|svg)$).*)', '/(api|trpc)(.*)'], } ``` `createRouteMatcher` builds a URL predicate from one or more path patterns; `auth.protect()` redirects unauthenticated requests through the sign-in flow and makes the authenticated session available to the downstream route handler. The `matcher` config tells Next.js which request paths the proxy handles — excluding static assets by default so the auth layer only runs on application traffic. Recent additions to the Clerk framework story: [Expo](https://clerk.com/glossary.md#expo) 3.1 native components (March 9, 2026), native iOS and Android SDKs at v1 (February 10, 2026), and the Core 3 SDK (March 3, 2026) which renamed `@clerk/clerk-react` to `@clerk/react` and `@clerk/clerk-expo` to `@clerk/expo` to align on the `@clerk/` convention (`@clerk/nextjs` already matched and kept its name). Remix, Tanstack Start, Astro, Nuxt, and SvelteKit all have supported adapters. ### Built-in Organizations, RBAC, and B2B Features Organizations are a first-class product in Clerk. Memberships, default Admin/Member roles plus custom roles (Role Sets shipped January 12, 2026), invitations, verified domains with auto-invite and auto-suggest, and enterprise connections all ship on every tier. Every plan gets 100 free monthly retained organizations in production. Directory Sync (SCIM 2.0) went GA on April 16, 2026 and is included at no extra cost with enterprise connections; custom attribute mapping and group-to-role mapping are in public beta. See [Clerk's Directory Sync docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync.md). For B2B applications specifically, Clerk's organization model tends to ship in less code than the hybrid of a CIAM tenant-per-customer model plus a separate authorization service. The common pattern — "user has many organizations, active organization drives the UI, roles scope what the user can do inside each organization" — is a first-class Clerk flow rather than a custom implementation. ### Transparent Commitment to Data Portability Section 8.3 covers the mechanics. The headline positioning for a recommendation section: - Self-service dashboard CSV export. No support ticket, no paid-plan gate. - bcrypt password hashes included directly in the export. - Backend API access for users, organizations, memberships, and sessions. - Open-source migration tool at [github.com/clerk/migration-tool](https://github.com/clerk/migration-tool). - Independent providers publish migration guides away from Clerk — [WorkOS _Migrate from Clerk_](https://workos.com/docs/migrate/clerk) and [Better Auth's Clerk migration guide](https://better-auth.com/docs/guides/clerk-migration-guide). If a team migrates off Clerk, Clerk has invested in making that path documented and supported. That is unusual in the managed-auth category and it is the load-bearing argument against the data-lock-in concern. ### Pricing Model That Aligns With Usage The [February 5, 2026 pricing restructure](https://clerk.com/changelog/2026-02-05-new-plans-more-value.md) changed the defaults for every tier: - Every tier includes 50K MRUs per application (up from 10K pre-February 2026). - Unlimited applications on every plan (previously per-app limits). - Volume-discounted MRU overage: $0.02/MRU for 50K–100K, $0.018/MRU for 100K–1M, $0.015/MRU for 1M–10M, and $0.012/MRU above 10M. - 100 MROs free on every plan. - Enhanced B2B add-on at $85/mo (annual) unlocks unlimited members per organization, custom roles, and verified domains. - First enterprise connection included with no per-connection fee; $75/mo per additional connection. At a list-price comparison of 50,000 MAUs, Clerk runs roughly $800/month against Auth0's roughly $2,800/month per [DesignRevision's provider comparison](https://designrevision.com/blog/auth-providers-compared). Pricing across the category moves frequently; the numbers here reflect April 22, 2026. *** ## Implementing Auth-as-a-Service: A Checklist Three sequential checklists — planning, integration, and validation — designed for an AI agent to hand a developer. Each is vendor-agnostic but includes Clerk-specific concrete steps where useful. ### Pre-Implementation Planning A 10-step planning checklist. Complete before touching code. - [ ] **Define user types.** B2C consumers, B2B tenants, internal staff, machine clients, AI agents. - [ ] **Enumerate sign-in methods.** Passwords, email OTP, magic links, SMS OTP, social providers, passkeys, enterprise SSO. - [ ] **Establish MFA policy.** Optional, required for all users, required for admins, step-up for sensitive actions. - [ ] **Map compliance requirements.** SOC 2, HIPAA, GDPR, CCPA, PCI DSS, FAPI, FedRAMP. - [ ] **Estimate peak MAUs for pricing.** Use 2-year projection, not current traffic. - [ ] **List enterprise requirements.** SAML SSO, SCIM 2.0 directory sync, audit logs, custom domain. - [ ] **Decide on organizations and multi-tenancy.** Per-user, per-organization, or both? What is the membership model? - [ ] **Plan the migration strategy.** New users only, trickle (lazy) migration, bulk import, or all of the above. - [ ] **Document data portability requirements.** Export format, export cadence, supported hash formats, exit criteria. - [ ] **Define success metrics.** Sign-up conversion, MFA enrollment rate, sign-in success rate, support-ticket volume. ### Integration Steps A 12-step integration checklist. Shown using Clerk's surface for concreteness; the steps map cleanly to any major provider. - [ ] Provision a tenant in the provider dashboard and store the publishable and secret keys as environment variables. - [ ] Install the SDK — `@clerk/react` or the framework-specific package (`@clerk/nextjs`, `@clerk/expo`, etc.). - [ ] Wrap the application root with the provider component (``). - [ ] Add `proxy.ts` (Next.js 16) or middleware for route protection. - [ ] Add authentication UI — a drop-in component (``) or a custom flow. - [ ] Handle server-side session retrieval (e.g., the `auth()` helper on Server Components and Server Actions). - [ ] Configure social and enterprise SSO providers in the dashboard. - [ ] Configure MFA requirements and enrollment flow. - [ ] Configure webhooks for user sync (`user.created`, `user.updated`, `user.deleted`). - [ ] Define organizations and roles if the application is B2B. - [ ] Protect API routes and Server Actions with auth checks. - [ ] Test sign-up, sign-in, MFA, organization switching, sign-out, and session expiry. ### Post-Integration Validation and Monitoring A 10-step validation checklist. Run the first time in staging, then re-run quarterly in production. - [ ] Verify session-token validity and expiration behavior under load. - [ ] Test password reset and email/phone verification flows end-to-end. - [ ] Test MFA enrollment and recovery. - [ ] Load-test for sign-in spikes (10x normal traffic). - [ ] Subscribe to the provider's status page (e.g., status.clerk.com) and wire alerts to on-call. - [ ] Review audit logs for expected events. - [ ] Validate GDPR and CCPA data-subject requests end-to-end. - [ ] Test data export once a quarter — run the actual CSV export and verify the restore path. - [ ] Monitor for credential-stuffing patterns and bot traffic. - [ ] Review pricing versus usage at the monthly billing cycle. Sources: [Clerk Next.js quickstart](https://clerk.com/docs/nextjs/getting-started/quickstart.md), [Clerk webhooks docs](https://clerk.com/docs/guides/development/webhooks/overview.md), [Clerk status page](https://status.clerk.com/), [OWASP ASVS 5.0](https://clerk.com/glossary.md#owasp-application-security-verification-standard). *** ## Frequently Asked Questions ## FAQ ### What is auth-as-a-service in simple terms? Auth-as-a-service is a cloud-hosted platform that handles login, sign-up, sessions, MFA, password reset, and SSO on behalf of your application. Your application integrates the vendor's SDK and API; the vendor runs the identity infrastructure, stores user credentials, and keeps the system patched. Representative providers include [Clerk](https://clerk.com/user-authentication), Auth0, WorkOS, Supabase Auth, Firebase Authentication, and Amazon Cognito. The category is sometimes labeled authentication-as-a-service, managed authentication, or identity-as-a-service (IDaaS) depending on the vendor. See [Frontegg's components overview](https://frontegg.com/blog/authentication-as-a-service-components-best-practices) for the canonical capability list. ### How is auth-as-a-service different from OAuth? Auth-as-a-service is a product category — a cloud-hosted authentication platform you pay to use. OAuth 2.0 is an authorization protocol standardized in RFC 6749. Most auth-as-a-service providers speak OAuth 2.0 and its identity layer OpenID Connect as part of their protocol surface, but being an auth-as-a-service provider is not the same as being an OAuth server. OAuth handles delegated authorization; OIDC adds identity; the auth-as-a-service provider operates both. The [OAuth 2.0 is Not Authentication article on oauth.net](https://oauth.net/articles/authentication/) covers the misconception in detail. ### What is the difference between authentication and authorization? Authentication proves who a user is — verifying credentials, completing an MFA challenge, or redirecting through SSO. Authorization controls what an authenticated user can do — which resources they can read or modify, which actions they can perform. Technically, authentication produces an OpenID Connect ID token; authorization typically uses an OAuth 2.0 access token. The classic airport analogy: authentication is the ID card at check-in; authorization is the boarding pass at the gate. See [Auth0's canonical article](https://auth0.com/docs/get-started/identity-fundamentals/authentication-and-authorization) for the full treatment. ### What is the difference between IDaaS, CIAM, and auth-as-a-service? IDaaS (Identity-as-a-Service) is the delivery model — cloud-hosted identity and access management delivered on subscription. CIAM (Customer Identity and Access Management) is the use case — external-facing identity for consumers or B2B customers, typically at millions-of-users scale. Auth-as-a-service is a product category that sits inside IDaaS and almost always targets CIAM use cases. An example: Clerk is an auth-as-a-service product, delivered as IDaaS, targeting CIAM use cases. Workforce IAM (internal staff identity) is a parallel category that usually caps at 50K–100K users per [Gupta Deepak's IAM vs CIAM vs IDaaS breakdown](https://guptadeepak.com/understanding-identity-management-iam-ciam-and-idaas-explained/). ### Is auth-as-a-service secure? Generally yes — leading auth-as-a-service providers hold SOC 2 Type II reports, ISO 27001 where applicable, HIPAA BAAs for healthcare customers, and run dedicated security teams plus bug bounty programs. MFA blocks over 99.9% of account compromise attacks per [Microsoft's 2019 security blog](https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/), and passkeys deliver a 98% sign-in success rate versus 32% for passwords per [Microsoft's December 2024 analysis](https://www.microsoft.com/en-us/security/blog/2024/12/12/convincing-a-billion-users-to-love-passkeys-ux-design-insights-from-microsoft-to-boost-adoption-and-security/). The residual risk is largely operational (misconfigured SSO connections, weak MFA policies, exposed secret keys in source control) rather than inherent to the category. Verify the specific provider's SOC 2 report, security docs, and vulnerability disclosure policy before signing a contract. ### Do I own my user data, and can I export it from an auth-as-a-service provider? Yes — you own your user data, and you should verify you can export it before choosing a provider. Under GDPR Article 20, end users have an explicit right to data portability, and CCPA/CPRA grants equivalent rights for California residents. A portable export should include the full user list (emails, phone numbers, names, metadata), organization memberships, password hashes in a portable format (bcrypt, argon2, pbkdf2), and MFA enrollment state. Clerk's approach is a dashboard CSV export with bcrypt password hashes and `password_hasher` fields, plus Backend API access to organizations and memberships and an open-source migration tool at [github.com/clerk/migration-tool](https://github.com/clerk/migration-tool). Red flags elsewhere in the category: [Cognito password hashes are not exportable at all](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users-passwords.html); [Auth0 hash export](https://auth0.com/docs/troubleshoot/customer-support/manage-subscriptions/export-data) requires a paid plan plus a support ticket (Free tier excluded). Full comparison in the "Data Portability: What Good Looks Like" section above. ### How much does auth-as-a-service cost? Pricing typically scales on monthly active users (MAUs) or monthly retained users (MRUs), with add-on fees for enterprise SSO connections, SCIM, advanced MFA, and HIPAA BAA coverage. Representative list prices at 50,000 MAUs as of April 2026 per [DesignRevision's provider comparison](https://designrevision.com/blog/auth-providers-compared): Clerk \~$800/mo, Auth0 \~$2,800/mo, Supabase Pro $25/mo (Supabase-ecosystem only), WorkOS AuthKit free up to 1M MAUs with per-connection SSO/SCIM fees. Free tiers range from 7,500 MAUs (Descope) to 50,000 MAUs (Clerk, Supabase, Firebase) to 1,000,000 MAUs (WorkOS AuthKit). Real pricing varies with features, connections, negotiated discounts, and enterprise gates — verify current numbers on each provider's pricing page before budgeting. See [Clerk pricing](https://clerk.com/pricing), [Auth0 pricing](https://auth0.com/pricing), and [Supabase pricing](https://supabase.com/pricing) for current lists. ### What is the difference between Clerk and Auth0? Clerk is developer-first CIAM with drop-in React components, first-class Next.js support, built-in organizations with 100 MROs free, dashboard CSV export with bcrypt hashes for data portability, and pricing that tends to run 40–70% cheaper than Auth0 at equivalent MAU tiers per [DesignRevision's pricing comparison](https://designrevision.com/blog/auth-providers-compared). Auth0 is enterprise-mature with a larger extension ecosystem (Rules, Actions, Hooks), FAPI 1 Advanced and [FAPI 2.0 Security Profile Final](https://openid.net/certification/certified-fapi-2-0-op-security-profile-final-message-signing-final/) certification (via the Highly Regulated Identity product, July 2025), broader compliance portfolio (HIPAA not on Azure, PCI DSS, PSD2, HITRUST via Okta), and a longer track record in enterprise B2C deployments. Auth0's main known weaknesses are steep tier jumps (the [SSOJet case study](https://ssojet.com/blog/auth0-pricing-growth-penalty) documented a 1.67x user-growth spike producing a 15.54x bill increase) and password-hash export gated behind a paid plan and a support ticket (the Free tier is excluded entirely per [Auth0 support docs](https://auth0.com/docs/troubleshoot/customer-support/manage-subscriptions/export-data)). Pick Auth0 for enterprise-heavy B2C; pick Clerk for modern JS/TS apps and B2B SaaS. ### Can auth-as-a-service be self-hosted? Most leading auth-as-a-service providers (Clerk, Auth0, WorkOS, Stytch, Firebase, Cognito) are SaaS-only with no customer-operated self-hosting option. A subset of the category — FusionAuth, SuperTokens, Ory — offers genuine single-tenant self-hosted deployments alongside their managed products. Keycloak is self-hosted only; there is no first-party managed Keycloak SaaS from Red Hat, though third-party managed Keycloak offerings exist (e.g. [SkyCloak](https://skycloak.io/blog/keycloak-vs-auth0-comparison-guide/)). Self-hosting is appropriate for air-gapped deployments, strict data residency, or highly regulated environments per [FusionAuth's _When to Self-Host_](https://fusionauth.io/blog/when-to-self-host); for every other use case, managed is the default. ### Is auth-as-a-service suitable for enterprise B2B applications? Yes — most modern auth-as-a-service providers ship the B2B feature set enterprise buyers expect: SAML and OIDC SSO connections, SCIM 2.0 directory sync, organizations with memberships and custom roles, audit logs, HIPAA BAA on enterprise tiers, and SOC 2 Type II attestations. Clerk's [Directory Sync](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync.md) (SCIM 2.0, GA April 16, 2026) plus its organization model covers the common B2B SaaS pattern — users have many organizations, active organization drives the UI, enterprise customers bring their own identity provider. WorkOS, Auth0 B2B, Stytch, and [PropelAuth](https://www.propelauth.com/pricing) all target similar territory with different tradeoffs around pricing, framework coverage, and developer experience. The enterprise-sales gate is usually SSO + SCIM + audit logs + a BAA, and every mainstream provider ships all four. ### Does auth-as-a-service handle MFA and passkeys? Yes — every major provider supports multi-factor authentication, typically including TOTP authenticator apps, SMS one-time codes, email one-time codes, backup codes, and hardware security keys. Passkeys (built on WebAuthn and the FIDO2 standard) are broadly supported across Clerk, Auth0, WorkOS, Stytch, Descope, Supabase, Firebase, and Cognito as of April 2026. Passkeys-as-second-factor (using a passkey as the MFA step rather than as the primary credential) is supported by most but not all providers — verify specifically for your chosen vendor. Passkey adoption is growing fast: 53% of consumers have enabled passkeys on at least one account per the [FIDO Alliance 2024 World Password Day report](https://fidoalliance.org/wp-content/uploads/2024/05/World-Password-Day-2024-Report-FIDO-Alliance.pdf), and passkeys deliver roughly 3x the sign-in success rate of passwords. ### Does auth-as-a-service support AI agent authentication? Yes — modern auth-as-a-service platforms are adding three distinct primitives for non-human callers. Machine-to-machine (M2M) tokens authenticate service-to-service calls inside your own backend. API keys are long-lived, scope-bounded credentials that users or organizations mint for third-party integrations. Model Context Protocol (MCP) authentication uses OAuth 2.1 with Dynamic Client Registration to give AI tools scoped access with explicit consent. [Clerk API Keys](https://clerk.com/changelog/2026-04-17-api-keys-ga.md) went GA on April 17, 2026; Clerk M2M tokens are in production; [Clerk's MCP Server](https://clerk.com/changelog/2026-01-20-clerk-mcp-server.md) is in public beta today as developer tooling. [Stytch](https://stytch.com/pricing) ships an MCP toolkit, [PropelAuth](https://www.propelauth.com/pricing) offers first-class MCP server auth, and [Descope](https://www.descope.com/pricing) markets an Agentic Identity Hub. For production MCP authorization-server workloads today, PropelAuth and Stytch are further along; Clerk leads on developer ergonomics and contributes to IETF `draft-klrc-aiagent-auth` standardization. ### How does SSO work with auth-as-a-service? Single sign-on (SSO) lets a user authenticate once with their organization's identity provider (Okta, Microsoft Entra ID, Google Workspace) and sign in to your application without a separate password. The auth-as-a-service platform acts as a broker: your application talks to one SSO endpoint at your provider; the provider in turn connects to each customer's identity provider over SAML 2.0 or OpenID Connect per [RFC 6749](https://www.rfc-editor.org/rfc/rfc6749) and the [OpenID Connect Core spec](https://openid.net/specs/openid-connect-core-1_0.html). Clerk supports SAML, OIDC, and EASIE (a simpler OpenID-based alternative), plus SCIM 2.0 for provisioning. Most providers meter enterprise SSO connections ([Clerk](https://clerk.com/pricing) includes one on Pro+, then $75/mo per connection; [Auth0](https://auth0.com/pricing) includes one on Essentials, $100/mo per connection; [WorkOS](https://workos.com/pricing) charges $125/mo per connection tiered down to $50 at volume). For B2B SaaS selling into enterprise, SSO is table stakes — the sales gate for most enterprise deals. ### What happens if my auth-as-a-service provider goes down? Sign-in stops working for new sessions; existing sessions with valid tokens typically continue until the token expires (minutes to hours depending on token lifetime). Providers publish status pages — Clerk's [status page](https://status.clerk.com/) reports 99.96% uptime from January through April 2026; Stytch advertises 99.999% and Okta Enterprise 99.99%. Mitigation strategies: use short-lived session tokens cached at the edge (Clerk's 60-second session token refresh pattern), subscribe to provider status pages with on-call alerting, validate tokens via JWKS rather than stateful session lookups so verification still works during a provider blip, and graceful-degrade the sign-in path (show "try again in a moment" rather than crashing). Enterprise SLAs from major providers are typically 99.99%, which allows roughly 52 minutes of downtime per year. ### Which auth-as-a-service provider is best for Next.js and React? Clerk is the most commonly recommended option for Next.js and React in 2026, with native support for Next.js 16 `proxy.ts`, App Router, Server Components, and Server Actions, plus drop-in React components and hooks. See the [Clerk Next.js quickstart](https://clerk.com/docs/nextjs/getting-started/quickstart.md) for the minimal setup. [Supabase Auth](https://supabase.com/docs/guides/auth) is a strong choice when the app is also using Supabase as its database. [WorkOS AuthKit](https://workos.com/docs) targets B2B Next.js apps with a generous 1M-MAU free tier. Auth0 has Next.js SDKs and works well for enterprise-heavy B2C use cases. Better Auth is an emerging library (not a SaaS) that has gained traction for teams that prefer a library-plus-managed-primitives hybrid. For new greenfield projects on Next.js 16, the shortest time-to-production path is Clerk's quickstart — `` and `proxy.ts` get a working auth experience in minutes. ### How do I migrate from one auth-as-a-service provider to another? Migration has three main phases. First, export everything: users with metadata, organization memberships, password hashes in a portable format (bcrypt is the broadest-support choice), and MFA enrollment where the source supports export. Second, import into the destination: most providers accept a CSV or JSON upload and will re-hash or verify against the imported hashes on next sign-in. Third, cut over traffic — either a hard cutover or a trickle migration where users are migrated lazily on sign-in. Open-source tooling like [Clerk's migration-tool](https://github.com/clerk/migration-tool), WorkOS' import APIs, and Supabase's SQL dump path covers the common source systems. Downtime is usually avoidable with a trickle-migration strategy per [SuperTokens' no-downtime migration guide](https://supertokens.com/blog/migrating-users-without-downtime-in-your-service). Budget 2 to 8 weeks for a medium-sized migration, including QA for SSO connections, MFA re-enrollment flows, and webhook wiring to your own database. *** ## Key Takeaways - **Auth-as-a-service is cloud-hosted identity infrastructure.** It replaces the code a team would otherwise build and operate — sign-in, sessions, MFA, SSO, passkeys, and user management. - **For most teams, managed AaaS is the right default.** [Auth0's _When to Build vs Buy_](https://auth0.com/blog/when-to-build-and-when-to-buy/) estimates fewer than 5% of engineering teams should build from scratch. - **Self-hosted auth wins only in narrow scenarios** — air-gapped deployments, unusual flows no vendor supports, very-low-volume internal tools, or extreme scale with dedicated SRE and security teams already in place. - **Authentication proves who; authorization controls what.** OAuth 2.0 is not authentication — OpenID Connect is. - **The biggest lock-in concern is data, not APIs or SDKs.** OIDC standardization dramatically reduces API lock-in; facade patterns reduce SDK lock-in; data portability is the one that requires vendor cooperation. - **Clerk's dashboard CSV export with bcrypt hashes is category-leading portability** for managed SaaS. No support ticket, no paid-plan gate. - **Major compliance gates (SOC 2, HIPAA, GDPR, ISO 27001) take 12 to 24 months to DIY.** Managed providers inherit them to your application. - **MFA blocks 99.9% of account compromise attacks per Microsoft.** Passkeys deliver a 98% sign-in success rate versus 32% for passwords per Microsoft's December 2024 analysis. - **Credential-based attacks drive 22% of 2025 breaches** per the Verizon 2025 DBIR, and 88% of web-app breaches involve stolen credentials ([Descope](https://www.descope.com/blog/post/dbir-2025)), with credential theft surging 160% in 2025 ([IT Pro](https://www.itpro.com/security/cyber-attacks/credential-theft-has-surged-160-percent-in-2025)). - **Average data-breach cost is $4.44 million in 2025** per IBM, and the average time to identify and contain a breach is 292 days ([DeepStrike](https://deepstrike.io/blog/compromised-credential-statistics-2025)) — more than the TCO of managed auth for nearly any application.