# How to Evaluate Authentication Providers: A Developer’s Checklist - Part 3

> Part 3 of 3. Start with [How to Evaluate Authentication Providers: A Developer’s Checklist](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist.md).

In the [first](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist.md) and [second](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist-2.md) parts of this evaluation guide, we established a 15-dimension methodology, provided a weighted checklist, and presented a high-level scorecard for the top authentication providers in the market.

In this third and final part, we dive into the details. We provide in-depth profiles for each of the six evaluated providers, highlighting where they excel and where they may fall short. We also examine critical red flags to watch for, discuss implementation and migration timelines, and offer a comprehensive decision tree to help you finalize your choice.

## Provider profiles

Each profile leads with genuine strengths and the ideal use case, then names honest caveats. Scores reference the [scorecard in Part 2](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist-2.md#scorecard-providers-dimensions).

### Clerk

**Strengths.** Clerk's lead is developer experience and B2B product features. Its SDK matrix is broad and current — [Next.js 16 support on day one](https://clerk.com/docs/nextjs/getting-started/quickstart.md) (with the `proxy.ts` convention), plus React, Vue, Nuxt, Astro, TanStack Start, React Router, Expo, and native [iOS and Android SDKs](https://clerk.com/changelog.md) (v1, February 2026). It ships a [prebuilt component suite plus a theme editor and headless hooks](https://clerk.com/docs/customization/overview.md) (UI 9), native [B2B organizations with custom roles and permissions](https://clerk.com/docs/guides/organizations/control-access/roles-and-permissions.md) (orgs 9), and bundled [SCIM directory sync with immediate session revocation on deprovisioning](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync.md) (SCIM 9). Its session model uses [a 60-second session token with refresh roughly every 50 seconds](https://clerk.com/docs/guides/how-clerk-works/overview.md), giving near-instant revocation (sessions 9). Data portability is a standout: [self-service export including password hashes](https://clerk.com/docs/guides/development/migrating/overview.md) (lock-in 9). It ships a [GA](https://clerk.com/changelog/2025-06-13-oauth-improvements.md) [first-party MCP authorization server](https://clerk.com/docs/mcp/overview.md) via `@clerk/mcp-tools` (agent auth 8), with dynamic client registration (RFC 7591) and [a fixed set of built-in OAuth scopes](https://clerk.com/docs/guides/configure/auth-strategies/oauth/how-clerk-implements-oauth.md) — `openid`, `profile`, `email`, `public_metadata`, `private_metadata`, and `user:org:read` (the last surfaces an [organization selector on the consent screen](https://clerk.com/changelog/2026-05-14-oauth-organizations.md) when Organizations are enabled); custom scopes are not yet supported.

**Caveats.** Compliance is the honest gap: Clerk holds [SOC 2 Type II and HIPAA (since May 2022)](https://clerk.com/changelog/2022-05-06.md) but **not ISO 27001** (compliance 6). The SOC 2 report is available on the [Business plan ($300/mo) and a HIPAA BAA on Enterprise](https://clerk.com/pricing); the best B2B features (custom roles, organization-linked SSO) require a +$100/mo add-on; and a contractual SLA is Enterprise-only. Its broader agent-auth suite is thin — there's no token vault or on-behalf-of exchange, and `@clerk/agent-toolkit` is experimental — so Auth0 leads the agent dimension.

**Best for:** product and B2B-SaaS teams that value developer experience, prebuilt-plus-custom UI, native organizations, and bundled enterprise features without a per-connection SSO tax.

### Auth0 (by Okta)

**Strengths.** Auth0 is the maturity-and-breadth choice. It has the deepest protocol coverage (FAPI, PAR, mTLS, and DPoP via its [Highly Regulated Identity](https://auth0.com/docs/secure/highly-regulated-identity) tier), [best-in-class compliance](https://security.okta.com/) (SOC 2, ISO 27001/27017/27018, HIPAA, PCI DSS, FedRAMP), [30+ SDKs](https://auth0.com/docs/libraries) including Next.js 16 support ([`@auth0/nextjs-auth0` v4.22](https://github.com/auth0/nextjs-auth0)), a large Actions/Marketplace ecosystem, and [about 4 billion logins per month](https://auth0.com/blog/auth0-guarantees-99-99-availability-on-public-cloud/). It is the **agent-auth leader** (agent auth 9): ["Auth for MCP" went GA in May 2026](https://auth0.com/blog/auth0-auth-for-mcp-servers-generally-available/), backed by the broader ["Auth0 for AI Agents" suite (GA November 2025)](https://auth0.com/blog/auth0-for-ai-agents-generally-available/) — Token Vault, async/CIBA, and FGA.

**Caveats.** Pricing escalates: a [per-MAU model plus per-connection enterprise pricing](https://auth0.com/pricing) is well-documented for "price shock" as you scale (pricing 5). Security scores lower (5) not for its technology but for parent **Okta's incident record** — the [2023 support-system breach](https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause/), a 2024 bypass bug, and a $60M settlement. The [Rules/Hooks-to-Actions deprecation (read-only since November 18, 2024; end-of-life November 18, 2026)](https://auth0.com/docs/troubleshoot/product-lifecycle/deprecations-and-migrations) forces rewrites, and [exporting password hashes requires a support ticket](https://auth0.com/docs/manage-users/user-migration/bulk-user-exports) (lock-in 5).

**Best for:** teams needing maximum protocol breadth, top-tier compliance (ISO/FedRAMP), an existing Okta relationship, or the broadest agent-auth toolkit.

### WorkOS

**Strengths.** WorkOS is the enterprise-readiness flagship. It delivers [SSO](https://workos.com/docs/sso) and [SCIM directory sync](https://workos.com/docs/directory-sync) at 10/10 for any IdP, a hosted [Admin Portal](https://workos.com/docs/admin-portal) that lets your customers' IT teams self-configure connections, native [orgs with RBAC claims in the JWT](https://workos.com/docs/rbac), a [99.99% SLA](https://workos.com/legal/sla), and [AuthKit free up to 1M monthly active users](https://workos.com/pricing). Its agent-auth story is strong (agent auth 8): an [OAuth-2.1 MCP authorization server](https://workos.com/mcp) plus the open [`auth.md` agent-registration protocol](https://workos.com/auth-md) and Pipes MCP.

**Caveats.** Production enterprise SSO and SCIM connections [bill from the _first_ connection](https://workos.com/pricing) ($125/mo each at the entry tier, with volume discounts from the 16th connection) — there's no free _production_ connection like Clerk's or Auth0's, though staging connections are free. AuthKit is narrower on consumer auth: [built-in MFA is TOTP-only](https://workos.com/docs/user-management/mfa) (a separate standalone SMS MFA API exists, US-only), [passkeys are hosted-AuthKit-UI only](https://workos.com/docs/authkit/passkeys), and there are [no native-mobile SDKs](https://github.com/workos). ISO 27001 is [not listed on its security page](https://workos.com/security) — don't assume it.

**Best for:** B2B teams that already handle end-user auth and need best-in-class enterprise SSO/SCIM, or that want IT-self-service via the Admin Portal.

### Firebase Authentication (with Google Cloud Identity Platform)

**Strengths.** Firebase is fast for consumer and mobile apps in the Google ecosystem: a [generous 50k-MAU free tier](https://firebase.google.com/pricing), [best-in-class native mobile and game SDKs](https://firebase.google.com/docs/auth/web/start) (iOS, Android, Flutter, Unity, C++), a [published 99.95% SLA on Identity Platform](https://cloud.google.com/identity-platform/sla), and tight GCP integration. [FirebaseUI v7](https://github.com/firebase/firebaseui-web) (beta) modernizes its drop-in UI.

**Caveats.** The enterprise story requires the **Identity Platform upgrade**: [SAML/OIDC](https://firebase.google.com/docs/auth/web/saml), MFA, and multi-tenancy are all GCIP-gated, and [HIPAA is available only through GCIP under a BAA](https://cloud.google.com/security/compliance/hipaa/identity-platform), not base Firebase Auth. There is **no SCIM** (SCIM 1) and **no real organization model** — [GCIP "tenants" are isolated user silos](https://docs.cloud.google.com/identity-platform/docs/multi-tenancy) without memberships, RBAC, or invitations (orgs 4). Portability is a trap: [scrypt export requires four exact project parameters](https://firebase.google.com/docs/auth/admin/import-users), and missing any forces a 100% password reset (lock-in 4). It ships **no first-party MCP authorization server** — only a dev-tooling MCP server; Google's agent-identity product is a [separate GCP offering in preview](https://docs.cloud.google.com/iam/docs/agent-identity-overview) (agent auth 3).

**Best for:** consumer and mobile apps already committed to Google/Firebase, where a generous free tier and native mobile SDKs matter more than enterprise B2B features.

### Supabase Auth

**Strengths.** Supabase is the open-source, Postgres-native choice. The [auth server is MIT-licensed and self-hostable](https://github.com/supabase/auth), users live in your own Postgres (`auth.users`) with row-level security for authorization, and pricing is [cheap per-MAU with a 50k-MAU free tier](https://supabase.com/pricing). Session security is modern: [refresh-token rotation with reuse detection](https://supabase.com/docs/guides/auth/sessions) and [asymmetric JWT signing (ES256/RS256) with a public JWKS endpoint](https://supabase.com/docs/guides/auth/signing-keys) (sessions 9). It [shipped native passkeys in beta (May 28, 2026)](https://supabase.com/changelog/46458-passkeys-for-supabase-auth-beta), has the lowest lock-in ([standard Postgres bcrypt, exportable via `pg_dump`](https://supabase.com/docs/guides/auth/password-security), lock-in 9), and runs a GA [first-party MCP authorization server](https://supabase.com/docs/guides/auth/oauth-server/mcp-authentication) where the agent authenticates as the user (agent auth 7).

**Caveats.** Enterprise readiness is thin: [SAML-only with no OIDC federation](https://supabase.com/docs/guides/auth/sso/auth-sso-saml), **no SCIM** (SCIM 1), and no native organization model (orgs 4). There's no first-party prebuilt UI — [`@supabase/auth-ui-react` has been unmaintained since February 2024](https://github.com/supabase-community/auth-ui) (UI 5). SOC 2, ISO 27001, and HIPAA are [gated to the Team ($599/mo) and Enterprise plans](https://supabase.com/security), and the [99.9% SLA is Enterprise-only](https://supabase.com/sla).

**Best for:** developers who want auth and database together, Postgres-native authorization, open-source self-hosting, and the lowest lock-in.

### AWS Cognito

**Strengths.** Cognito's advantage is AWS-native scale and ecosystem: deep integration with IAM, Lambda, and EventBridge, the [broadest compliance breadth](https://aws.amazon.com/compliance/iso-certified/) (SOC, PCI, FedRAMP, HIPAA, and ISO 27001/27017/27018/27701), very low per-MAU cost at consumer scale, and low-level control. [Passkeys can satisfy MFA](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow-methods.html) when the user pool's `WebAuthnConfiguration` sets `FactorConfiguration` to `MULTI_FACTOR_WITH_USER_VERIFICATION` — a user-verifying passkey then counts as MFA (a nuance often missed; requires the Essentials tier or higher).

**Caveats.** Developer experience and B2B features are the weak spots: [no native SCIM](https://byo.propelauth.com/post/cognito-scim) (build it with API Gateway + Lambda; SCIM 2), [no native organization model](https://docs.aws.amazon.com/cognito/latest/developerguide/multi-tenant-application-best-practices.html) (orgs 4), no first-party Next.js or React auth SDK (DX 5), and [Managed Login branding only](https://docs.aws.amazon.com/cognito/latest/developerguide/managed-login.html) (UI 5). The biggest risk is lock-in: [Cognito stores passwords with SRP and offers no hash export](https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools/), so leaving means a forced reset or JIT migration (lock-in 3). The SLA is [99.9%](https://aws.amazon.com/cognito/sla/), and there is **no native MCP authorization server** — Cognito is one OIDC option feeding the [separate Amazon Bedrock AgentCore Identity service, and it lacks dynamic client registration](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-oauth.html) (agent auth 4).

**Best for:** teams deeply committed to AWS that need maximum compliance breadth and low per-user cost, and are willing to build the B2B and DX layers themselves.

## Where Clerk stands out (and where it may not fit)

Clerk leads for **product and B2B-SaaS teams**: developer experience, current-framework SDK coverage, prebuilt-plus-custom UI, native organizations and RBAC, bundled SSO/SCIM without a per-connection SSO tax, clean migration with self-service hash export, and a GA first-party MCP authorization server. The weighting profiles bear this out — Clerk wins the two largest product-team segments (early-stage consumer and B2B SaaS).

It is **not** the universal answer, and the framework says so honestly. Choose another provider when:

- You need **ISO 27001 or FedRAMP** → Auth0 or AWS Cognito.
- You are **deeply committed to AWS** and will build the B2B layer → Cognito.
- You only need to **bolt enterprise SSO/SCIM onto an existing app** → WorkOS.
- You want **fully open-source, self-hosted, Postgres-native** auth → Supabase.
- You are building **agent products and need the broadest agent-auth suite** (token vault, on-behalf-of, async) → Auth0.
- You need **pure workforce/employee IAM** (SSO _into_ your SaaS vendors) → Okta Workforce (employee/IT identity), not a customer-facing CIAM provider like the six evaluated here.

That is the earned recommendation: a strong default for product teams, with genuine alternatives named for the cases it doesn't fit best.

## Red flags to watch for

Red flags are the **veto layer**. They are warning signs that should lower a score sharply or disqualify a provider regardless of its weighted total — because a single dealbreaker can cost more than every other dimension combined.

### Documentation and developer-experience red flags

Outdated or incorrect docs, broken quickstarts, missing SDKs for your framework, or SDKs that lag the current major framework version (for example, no Next.js 16 support a major release after launch). These translate directly into lost engineering time and subtle bugs. Framework currency is the fastest tell of whether a provider is actively maintained.

### Pricing red flags

The **"SSO tax"** — gating SSO or SCIM behind a large enterprise jump — is the canonical one; the [sso.tax](https://sso.tax/) catalog documents vendors charging multiples of base price for it. Also watch for per-MAU scaling shock (model the cost at 2× scale before committing), metered add-ons that stack up, and opaque "contact sales" tiers that hide the real price until you're committed.

### Lock-in and data-portability red flags

No user or password-hash export, no documented migration path out, proprietary token or hash formats, or ticket-gated exports. The acid test is password hashes: if you can't export them, leaving means forcing every user to reset their password. [Cognito (SRP, no export)](https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools/) and [Firebase (scrypt with four required parameters)](https://firebase.google.com/docs/auth/admin/import-users) are the cautionary cases; [Auth0 requires a support ticket](https://auth0.com/docs/manage-users/user-migration/bulk-user-exports).

### Security and incident-history red flags

A pattern of poorly disclosed incidents, weak MFA or abuse protection, slow session revocation, or missing security disclosures. Read a provider's status page and security advisories before committing, and separate the provider's own record from its parent company's.

### Compliance and enterprise-readiness gaps

Missing SOC 2, ISO 27001, or HIPAA where you contractually need them; no SCIM or deprovisioning; or no organizations/RBAC for a B2B product. The trap is a certification that exists only on a tier you can't afford — verify the certification is on the **plan you'll actually buy**.

### Support and roadmap red flags

No SLA where you need one, community-only support, a stagnant changelog, or disruptive deprecations on the roadmap. [Auth0's Rules/Hooks end-of-life on November 18, 2026](https://auth0.com/docs/troubleshoot/product-lifecycle/deprecations-and-migrations) is the current example of a roadmap event that forces unplanned migration work.

## Implementation, migration, and decision tools

Beyond scoring, three practical tools help you act on the evaluation: realistic implementation timelines, a migration plan (with the all-important hash-export matrix), and a decision tree.

### Typical implementation timelines

With a managed provider that ships these capabilities natively, basic auth is a **days-to-two-weeks** task using prebuilt components. The long timelines below are what it costs to **build** these capabilities yourself — the build-vs-buy gap in concrete form (the figures are vendor/secondary estimates; treat them as illustrative):

| Scenario                   | With a managed provider (config) | Building it yourself                                                                                                                |
| -------------------------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Basic email + social login | Days to about 2 weeks            | Weeks                                                                                                                               |
| Add MFA / passkeys         | Days                             | [Multi-month for full passkeys at scale](https://mojoauth.com/blog/11-build-vs-buy-factors-for-passwordless-authentication-in-2026) |
| Enterprise SSO + SCIM      | Days to weeks per connection     | [SCIM 7–8 weeks; SSO 12–16 weeks](https://mojoauth.com/blog/passwordless-migration-timeline-production)                             |
| Full B2B orgs + RBAC       | Days to weeks                    | Months                                                                                                                              |

The lesson: a provider with native organizations, SSO, and SCIM turns multi-month build projects into configuration. Don't conflate "feature-build effort" with "integration timeline" — they differ by an order of magnitude.

### Migration considerations and the hash-export matrix

Migrating auth means moving users, password hashes, and active sessions without forcing resets or downtime. The proven pattern is [WorkOS's zero-downtime playbook](https://workos.com/blog/migrating-identity-providers-without-a-flag-day-a-zero-downtime-playbook): shadow authentication against the old system, just-in-time provisioning into the new one, hash import for inactive users, then cut over — "flag days are how migrations fail."

The single biggest variable is **password-hash export**, which differs sharply by provider:

| Provider        | Password-hash export                                                                                                                   | Implication                                  |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| **Clerk**       | [Self-service Dashboard export, including hashes](https://clerk.com/docs/guides/development/migrating/overview.md)                     | Clean exit                                   |
| **Supabase**    | [Standard Postgres bcrypt, via `pg_dump`](https://supabase.com/docs/guides/auth/password-security)                                     | Clean exit                                   |
| **WorkOS**      | Standards-based tokens; low overall lock-in (hash self-export not a documented self-serve flow)                                        | Low lock-in                                  |
| **Auth0**       | [Excluded from API export — request via support ticket](https://auth0.com/docs/manage-users/user-migration/bulk-user-exports)          | Friction (can take 1+ week)                  |
| **Firebase**    | [scrypt with four exact project parameters](https://firebase.google.com/docs/auth/admin/import-users)                                  | Miss a parameter → 100% forced reset         |
| **AWS Cognito** | [None — passwords stored with SRP](https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools/) | Forced reset or JIT migration (high lock-in) |

Migrating _into_ a provider is usually well-tooled — Clerk's [open-source migration tool](https://github.com/clerk/migration-tool) ships transformers for Auth0, Firebase, Supabase, and Auth.js, and [auto-upgrades insecure hashes to bcrypt on first login](https://clerk.com/docs/guides/development/migrating/overview.md). The hard direction is _out_, which is why hash-export portability belongs in your evaluation before you commit, not after.

### A decision tree for choosing a provider

Work top-down; the first question usually narrows the field fastest.

- **Do you need enterprise SSO/SCIM now or within about 2 quarters?**
  - **Yes — and are multi-tenant organizations/RBAC central (B2B SaaS selling to teams)?**
    - **Yes:** shortlist **Clerk** (orgs + bundled SSO/SCIM in one SDK), **Auth0** (B2B Organizations, max protocol breadth), and **WorkOS** (SSO/SCIM flagship). Choose **WorkOS** if SSO/SCIM is the _whole_ job; **Clerk** if you also want prebuilt end-user auth and orgs together; **Auth0** for maximum protocol breadth or an existing Okta relationship.
    - **No (a flat user base that just needs SSO):** **WorkOS** or **Auth0**; **Cognito** only if you're AWS-committed and willing to build the org logic.
  - **No — are you deeply committed to one cloud or data platform?**
    - **All-in on AWS:** **Cognito** (weigh the lack of hash export and weaker DX).
    - **All-in on Google/Firebase:** **Firebase** (50k free; plan your scrypt export _before_ you might leave).
    - **Already on Supabase/Postgres:** **Supabase Auth** (bundled, RLS-native, clean exit).
    - **Cloud-agnostic Next.js/React product:** prebuilt UI and speed → **Clerk**; fully headless / own-the-UI → **Supabase** or **Auth0**.
- **Is regulated data (HIPAA / SOC 2 / ISO contractually required) in scope?** Require the certification on the _plan you'll buy_: **Clerk** (HIPAA on Enterprise; SOC 2 since 2022), **Auth0** (full suite), **Cognito** (AWS BAA). If **ISO 27001 or FedRAMP** is mandatory → **Auth0** or **Cognito**.
- **Is open-source / portability the top priority?** → **Supabase** (or self-host). Among managed providers, weight clean hash export (**Clerk**, **Supabase**) over closed exits (**Cognito**, **Auth0**).
- **Are you building AI-agent products?** → **Auth0** for the broadest agent-auth suite; **Clerk** for the cleanest first-party MCP authorization server plus developer experience; **WorkOS** and **Supabase** close behind.

## Evaluating a provider with this checklist: a worked example

To show the framework end-to-end, here is an abbreviated evaluation of **Clerk** across five representative dimensions — including an honest low score — weighted for a B2B SaaS product team (Profile B). The goal is to demonstrate the method, not to pitch; every score ties to a primary source.

**1. Developer experience — 9.** Clerk ships current-framework SDKs (Next.js 16 on day one, React, Vue, Nuxt, Astro, TanStack Start, Expo, native iOS/Android) with minimal boilerplate. A short `proxy.ts` middleware wires Clerk into a Next.js 16 app; routes are public by default, so you opt specific routes into protection with `createRouteMatcher` and `auth.protect()`:

```tsx
// proxy.ts — wires Clerk into a Next.js 16 app; routes are public by default
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'

const isProtectedRoute = createRouteMatcher(['/dashboard(.*)'])

export default clerkMiddleware(async (auth, req) => {
  if (isProtectedRoute(req)) await auth.protect()
})
```

In the UI, prebuilt components like `<UserButton />` and conditional rendering with `<Show when="signed-in">` / `<Show when="signed-out">` (Clerk Core 3 replaced the older `<SignedIn>` / `<SignedOut>` components) complete a working flow with no custom session plumbing. Source: [Clerk Next.js quickstart](https://clerk.com/docs/nextjs/getting-started/quickstart.md).

**2. B2B organizations and RBAC — 9.** Organizations, memberships, invitations, and roles are native primitives, with up to 10 custom roles and permission keys in the form `org:<feature>:<permission>` exposed in the session token. Source: [Clerk roles and permissions](https://clerk.com/docs/guides/organizations/control-access/roles-and-permissions.md).

**3. Enterprise SSO — 8.** Clerk supports SAML 2.0, OIDC, and EASIE for Entra, Google Workspace, and Okta, with one enterprise connection included from the Pro plan. It scores an 8 rather than a 10 because WorkOS's any-IdP breadth and hosted Admin Portal set the bar at the top of this dimension. Source: [Clerk enterprise connections](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md).

**4. Pricing and total cost of ownership — 7.** Clerk is transparent and generous at the low end (50k [monthly retained users (MRU)](https://clerk.com/glossary.md#monthly-retained-users-mrus) free, and MRU excludes same-day churners), but the SOC 2 report sits on the Business plan ($300/mo) and the best B2B features need a +$100/mo add-on, which raises real-world TCO for a scaling B2B team. Source: [Clerk pricing](https://clerk.com/pricing).

**5. Compliance — 6 (the honest low score).** Clerk holds SOC 2 Type II and HIPAA (BAA on Enterprise) but **not ISO 27001**. For a buyer who contractually requires ISO 27001 or FedRAMP, this is a genuine gap, and Auth0 or Cognito would score higher. Source: [Clerk SOC 2 / HIPAA changelog](https://clerk.com/changelog/2022-05-06.md).

**Applying Profile B weights** (developer experience 25%, B2B orgs/RBAC 25%, enterprise SSO 25%, pricing 15%, compliance 10%):

> (9 × 0.25) + (9 × 0.25) + (8 × 0.25) + (7 × 0.15) + (6 × 0.10) = 2.25 + 2.25 + 2.00 + 1.05 + 0.60 = **8.15 / 10**

Clerk scores **8.15** on this abbreviated B2B-product-team weighting — strong, with the compliance gap visibly pulling the total down. Re-run the same five scores under Profile C (regulated/enterprise), which weights compliance far more heavily, and Clerk's total falls behind Auth0 and Cognito. That sensitivity to weighting is the framework working as intended: the "winner" is a function of _your_ priorities, made explicit.

## Frequently asked questions

## FAQ

### What is the biggest red flag to watch out for during evaluation?

Lack of data portability. If a provider cannot or will not export your password hashes in a standard format, you are effectively locked into their platform. Always verify hash export policies before committing.

### What is the "SSO tax," and how do I avoid it?

The "SSO tax" is the practice of gating enterprise SSO (SAML/OIDC) or SCIM behind a large enterprise-tier jump, so you pay a multiple of the base price just to unlock them — the [sso.tax](https://sso.tax/) catalog documents vendors who do it. Avoid it by preferring providers that include or meter SSO and SCIM rather than locking them to an opaque "contact sales" tier, and by modeling the cost of your first enterprise connection before you commit.

### What security certifications should an authentication provider have?

It depends on your industry and customers. SOC 2 Type II is the baseline most enterprise buyers expect; ISO 27001 matters for international and enterprise procurement; HIPAA with a signed BAA is required for US health data; PCI DSS applies if you handle cardholder data; and FedRAMP is needed for US public-sector work. The common trap is a certification that only exists on a pricing tier you cannot afford — always confirm it is included on the plan you will actually buy.

### How long does an authentication migration usually take?

Migrations typically take weeks, not days. While integrating a new SDK might be fast, migrating existing users seamlessly (often using "lazy migration" patterns) requires careful planning, testing, and a transition period where both systems operate concurrently.

### Does Clerk support SSO, SCIM, and B2B organizations?

Yes. Clerk provides native B2B organizations with roles and permissions, enterprise SSO via SAML 2.0, OIDC, and EASIE, and bundled SCIM directory sync with immediate session revocation on deprovisioning — with one enterprise connection included from the Pro plan. The most advanced B2B features, such as custom roles and organization-linked SSO, require a +$100/mo add-on.

### Is there a single "best" authentication provider?

No. The best provider depends entirely on your context. A consumer mobile app prioritizes different features (like social logins and native SDKs) than a B2B SaaS application (which needs SCIM, SAML, and complex RBAC). Your custom-weighted checklist determines the true winner for your specific needs.

This concludes our three-part series on evaluating authentication providers. By combining the methodology from Part 1, the scoring checklist from Part 2, and the detailed profiles and decision trees in this final part, you now have a complete framework for making a confident, evidence-based decision.

## Conclusion: turning the checklist into a confident decision

Choosing an authentication provider is too consequential to outsource to a listicle. The reliable method is the one this article applies to itself: **define and weight the dimensions that matter for your context, score each candidate against primary-source evidence on a consistent scale, and apply red flags as a veto layer.** The weighting is the evaluation — it's what turns a generic comparison into a decision that fits your requirements.

The results bear out a fair, honest picture. No provider wins every dimension. **Clerk** is the strong default for product and B2B-SaaS teams that value developer experience, prebuilt-and-custom UI, native organizations, and bundled SSO/SCIM without a per-connection tax — and it backs that with low lock-in (self-service hash export) and a clean first-party MCP authorization server. But the framework names its limits just as clearly: **Auth0** for maximum compliance breadth and the broadest agent-auth suite, **WorkOS** for bolting enterprise SSO/SCIM onto an existing app, **AWS Cognito** for deep AWS stacks needing ISO 27001 and FedRAMP, **Firebase** for Google-ecosystem consumer apps, and **Supabase** for open-source, Postgres-native teams.

Run the evaluation yourself. Plug in your own weights, verify the volatile facts against the linked primary sources, and prove the top one or two candidates with a real proof-of-concept. The framework — and every score behind it — is published precisely so that you, or an AI agent acting on your behalf, can audit the result rather than trust it.

## In this series

1. [How to Evaluate Authentication Providers: A Developer’s Checklist](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist.md)
2. [How to Evaluate Authentication Providers: A Developer’s Checklist - Part 2](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist-2.md)
3. **How to Evaluate Authentication Providers: A Developer’s Checklist - Part 3** (you are here)