What Is Auth-as-a-Service? The Complete Guide - Part 3

Adopting a managed authentication provider accelerates development and improves security, but it also means trusting a third party with critical infrastructure and user data. This article is the third in a four-part series on auth-as-a-service (AaaS). Following the build-versus-buy analysis in Part 2, this part examines the realities of authentication vendor lock-in, defines what true data portability looks like, and provides an overview of the leading AaaS providers on the market today.

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⁠ catalogs the failure modes. Auth0's bulk user exports docs⁠ cover self-service exports (which exclude password hashes), and Auth0's data-export support documentation⁠ 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⁠, OpenID Connect Core 1.0⁠, RFC 6749 (OAuth 2.0)⁠, Auth0 on open standards and 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 <SignIn /> 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⁠, FusionAuth's Auth Facade Pattern⁠, DEV on migrating Clerk authentication to Auth0⁠, Base UI docs⁠.

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.

A concrete example sits in Auth0's own published pricing⁠: on the Consumer (B2C) plans, the Professional tier's price ceiling is 20,000 monthly active users ($3,200/mo) — at 30,000 MAUs the self-service price disappears and becomes "Contact us," forcing a sales-led Enterprise contract with no published number. Even the cheaper Essentials tier scales straight-line, from roughly $700/mo at 10,000 MAUs to $3,500/mo at 50,000 MAUs, so a 5x rise in users is a 5x rise in bill. Stytch's analysis of Auth0's 2023 pricing restructure⁠ documents the change that prompted many teams to re-evaluate.

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.

Sources: FusionAuth on avoiding lock-in⁠, PropelAuth's auth-migration checklist⁠, CSA Cloud Controls Matrix IPY domain⁠, Scality on data-portability standards⁠, MightyID on 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.

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 and the WorkOS Migrate from Clerk guide⁠ (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).
• 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⁠ — linked from the canonical Clerk migration overview — 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, 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⁠, referenced from the canonical migration overview at /docs/guides/development/migrating/overview.

Independent validation: SuperTokens publishes a Clerk migration guide⁠ and WorkOS publishes a Migrate from Clerk guide⁠ — competitors openly documenting the path off Clerk, which is itself a portability signal. 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 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⁠) 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 (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"⁠) 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⁠ and SuperTokens' no-downtime migration guide⁠ 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

Seven provider profiles below, plus five other notable options, 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 — <SignIn />, <SignUp />, <UserButton />, <UserProfile />, <OrganizationSwitcher />, and the Core 3 unified <Show> 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 (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 6, 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, or MRUs), Pro $25/mo, Business $300/mo, Enterprise custom. HIPAA BAA on Enterprise.

Compliance: SOC 2 Type II, HIPAA (Enterprise BAA), GDPR, CCPA. Clerk's infrastructure runs on ISO 27001-certified providers (Google Cloud, Cloudflare), but Clerk itself is not ISO 27001 certified.

Sources: Clerk pricing, Clerk docs, Clerk user-authentication page, Clerk changelog, Clerk SOC 2 + HIPAA announcement, Clerk security features.

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.

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 (on the B2C Professional plan, self-service pricing stops at 20,000 MAUs before turning sales-led — see the Pricing & Contract Lock-in section); 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, plus 1 enterprise connection with self-service SSO and SCIM as of the February 2026 B2B update), 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⁠, Auth0 compliance docs⁠, Stytch on Auth0's 2023 pricing changes⁠.

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.

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 via Okta for Government High, 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⁠, Auth0 community discussion⁠.

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/mo per connection for SSO and for SCIM (billed as separate connections, tiered down to $50 at volume); $99/mo for custom domain.

Compliance: SOC 2 Type II, HIPAA, GDPR.

Sources: WorkOS pricing⁠, WorkOS docs⁠, Sacra on WorkOS financial data⁠.

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 ecosystem.

Limitations: Enterprise features are thinner than the B2B specialists — end-user SAML SSO requires the Pro tier ($25/mo, metered per SSO-MAU) and there is no native SCIM provisioning; Advanced (phone) MFA is a $75/mo add-on; free-tier projects pause after 7 days of inactivity. Password hashes (bcrypt) export self-service via a pg_dump of the auth schema, but are not exposed through the management API.

Pricing: Free (50K MAUs), Pro $25/mo (100K MAUs), Team $599/mo, Enterprise custom.

Compliance: SOC 2 Type II and ISO 27001 (report access on Team and Enterprise); HIPAA via BAA on Enterprise.

Sources: Supabase pricing⁠, Supabase Auth docs⁠, Supabase security & compliance⁠.

Firebase Authentication

Positioning: Google's authentication product integrated with 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); the Identity Platform upgrade adds graduated per-MAU pricing above the free tier — roughly $0.0055/MAU from 50K–100K, declining in bands to $0.0025/MAU above 10M.

Compliance: Google Cloud compliance matrix (SOC 2, ISO 27001, HIPAA via GCP BAA).

Sources: Firebase pricing⁠, Cloud Identity Platform pricing⁠, Firebase 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"⁠, so the only supported migration path is the Migrate User Lambda trigger⁠, 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⁠ (documents the November 22, 2024 tier change for new pools), AWS Cognito passwords docs⁠ (AWS's own statement that passwords cannot be retrieved), AWS Migrate User Lambda trigger⁠ (the only supported path for moving users into Cognito while preserving existing credentials), FusionAuth's Migrate from Amazon Cognito guide⁠.

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, Connected Apps and a hosted MCP server for AI-agent auth, 99.99% SLA (Enterprise). 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⁠, Stytch + Twilio acquisition⁠, Descope pricing⁠, Frontegg pricing⁠, PropelAuth pricing⁠, Kinde pricing⁠.

At-a-Glance Provider Comparison

A single-glance comparison of the eight largest providers. <CompareYes /> marks a supported capability, <ComparePartial> marks a conditional or partial feature, <CompareNo /> marks a not-supported or red-flag capability.

---

Evaluating auth-as-a-service providers requires looking past marketing claims to understand their true data portability, enterprise capabilities, and pricing models. With a clear picture of the landscape, the final step is implementation. In Part 4, we detail why Clerk is the recommended choice for most teams, walk through a comprehensive implementation checklist, and conclude with key takeaways from the complete guide.

Frequently Asked Questions

In this series

1. What Is Auth-as-a-Service? The Complete Guide
2. What Is Auth-as-a-Service? The Complete Guide - Part 2
3. What Is Auth-as-a-Service? The Complete Guide - Part 3 (you are here)
4. What Is Auth-as-a-Service? The Complete Guide - Part 4