# What Is Auth-as-a-Service? The Complete Guide - Part 3 > Part 3 of 4. Start with [What Is Auth-as-a-Service? The Complete Guide](https://clerk.com/articles/what-is-auth-as-a-service-the-complete-guide.md). # 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_](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. A concrete example sits in [Auth0's own published pricing](https://auth0.com/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](https://stytch.com/blog/auth0-2024-pricing-update) 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. - [ ] 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 `pg_dump` | Yes bcrypt | No | 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) and [WorkOS publishes a _Migrate from Clerk_ guide](https://workos.com/docs/migrate/clerk) — 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](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 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 — ``, ``, ``, ``, ``, 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 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](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. Clerk's infrastructure runs on ISO 27001-certified providers (Google Cloud, Cloudflare), but Clerk itself is not ISO 27001 certified. 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 SOC 2 + HIPAA announcement](https://clerk.com/changelog/2022-05-06.md), [Clerk security features](https://clerk.com/features/security). ### 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 (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](https://auth0.com/pricing), [Auth0 compliance docs](https://auth0.com/security), [Stytch on Auth0's 2023 pricing changes](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 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](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/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](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:** 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](https://supabase.com/pricing), [Supabase Auth docs](https://supabase.com/docs/guides/auth), [Supabase security & compliance](https://supabase.com/security). ### 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); 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](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, 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](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 | No | Yes **Dashboard CSV (bcrypt)** | Next.js, React, Remix, Expo, React Native, iOS, Android (native), Go, Python, Ruby | | Auth0 | 25K | Yes | Yes | Yes (1 free) | Yes (1 free) | 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 | Beta | Pro ($25) + per-MAU | No | Limited | Enterprise | Yes | Yes `pg_dump` (bcrypt) | Supabase ecosystem | | Firebase | 50K | Yes (SMS/TOTP) | Yes | Identity Platform upgrade | No | Identity Platform | Via GCP BAA | Via GCP | CLI (modified scrypt) | Mobile-first | | Cognito | 10K (new) / 50K (legacy) | Yes | Yes | Yes | No | 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 | Growth tier | Yes | Yes API | Broad | > Pricing and feature limits change frequently. Verify current details on each provider's pricing page before making a purchase decision. *** 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 ## FAQ ### Can I export my users if I change authentication providers? It depends on the provider. True data portability requires the ability to export your full user inventory, including password hashes in a standard format (like bcrypt), ideally via self-service. Some providers gate password hash exports behind support tickets or paid plans, while others use proprietary hash formats that are difficult to import elsewhere. ### How does SSO work with auth-as-a-service? The provider brokers it. Your app connects to one endpoint at the provider; the provider connects to each customer's identity provider (Okta, Microsoft Entra ID, Google Workspace) over SAML 2.0 or [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html), so users sign in with their employer's IdP and no separate password. Clerk adds EASIE (a simpler OpenID alternative) and SCIM 2.0 provisioning. Most providers meter enterprise connections, making SSO the usual B2B sales gate. ### How can I minimize SDK lock-in with an authentication provider? You can reduce SDK lock-in by building your UI on headless primitives (so the component behavior belongs to your app), wrapping the provider's SDK in a thin facade module, and preferring server-side session validation via JWKS or OIDC userinfo over vendor-specific SDK session hooks. ## In this series 1. [What Is Auth-as-a-Service? The Complete Guide](https://clerk.com/articles/what-is-auth-as-a-service-the-complete-guide.md) 2. [What Is Auth-as-a-Service? The Complete Guide - Part 2](https://clerk.com/articles/what-is-auth-as-a-service-the-complete-guide-2.md) 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](https://clerk.com/articles/what-is-auth-as-a-service-the-complete-guide-4.md)