# How to Evaluate Authentication Providers: A Developer’s Checklist - Part 2 > Part 2 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 part](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist.md) of our guide on evaluating authentication providers, we established a scoring methodology and examined the first seven foundational dimensions, including authentication methods, enterprise SSO, and session management. In this second part, we continue the evaluation framework by exploring dimensions 8 through 15. We will focus heavily on developer experience, pricing, scalability, and emerging trends like AI agent authentication. We will then assemble these dimensions into a weighted evaluation checklist and present a high-level comparison scorecard for the leading authentication providers. ### 8. Developer experience — SDKs and framework coverage **What it is.** The breadth and quality of SDKs: Next.js, React, Vue/Nuxt, Astro, TanStack Start, React Router, Expo/React Native, native iOS/Android, and backend SDKs — plus how current they are with the frameworks you use. **Why it matters.** DX is not a vanity metric; it's time-to-ship and ongoing maintenance cost. A missing SDK for your framework means you build and maintain an integration yourself. **Framework currency is a quality signal**: an auth SDK that supports the current major version of your framework on day one (for example, [Next.js 16](https://nextjs.org/blog/next-16) and its `proxy.ts` convention) signals an actively maintained product; one that lags by a major version is a red flag. **What "good" looks like.** First-party SDKs for the frameworks you actually use, kept current with new major releases, with typed APIs and minimal boilerplate to wire up auth. **Questions to ask:** - Is there a first-party, actively maintained SDK for your exact framework (frontend and backend)? - Does it support the current major version of that framework? - Are native mobile SDKs (iOS/Android, Expo) available if you need them? - How much code does it take to protect a route and read the current user? ### 9. UI components, customization, and branding **What it is.** Whether the provider ships prebuilt, drop-in UI (sign-in, sign-up, user profile, organization switcher) versus fully headless flows you build yourself, plus theming/appearance control, localization, and whether you can avoid redirecting users to a hosted page. **Why it matters.** Prebuilt components are the fastest path to a polished, accessible, secure auth UI; headless control is the path to a fully custom experience. The best providers offer both. A forced redirect to a hosted, hard-to-brand page is a UX and conversion cost. **What "good" looks like.** Drop-in components for speed _and_ headless primitives for control, with a real theming/appearance API, localization, and the option to keep users on your domain. **Questions to ask:** - Are there prebuilt components, headless hooks, or both? - How much can you theme the UI, and can you keep users on your own domain? - Is localization supported for your target markets? - How constrained is the hosted UI if you must use it? ### 10. Documentation quality **What it is.** The accuracy, completeness, and currency of the docs — working quickstarts, current framework examples, complete API references, and clear migration guides. **Why it matters.** Documentation is the interface you actually use day to day. Outdated or incorrect docs (examples for an old framework version, broken quickstarts) translate directly into lost developer time and subtle bugs. **What "good" looks like.** Quickstarts that work on the current framework version, accurate and complete API references, and docs that are updated alongside releases. (Some providers also ship a developer-tooling MCP server that feeds AI coding assistants accurate SDK snippets — a documentation/DX aid, distinct from the agent-authorization capability in dimension 15.) **Questions to ask:** - Do the quickstarts work on the current version of your framework, unmodified? - Are API references complete and current? - Are migration guides (in and out) documented? - How quickly are docs updated after a release? ### 11. Pricing and total cost of ownership **What it is.** The pricing model (per–monthly-active-user, per-user, or flat), free-tier limits, how cost scales, and how enterprise features (SSO, SCIM, MFA, compliance) are gated. **Why it matters.** Pricing models differ enough that headline per-user rates are not comparable. Some providers bill per **MAU** ([monthly active user](https://clerk.com/glossary.md#monthly-active-users-maus)), counting anyone who authenticates — and definitions vary: [Auth0 counts a login or token refresh per tenant](https://auth0.com/blog/auth0-monthly-active-user-mau-explained/) (one user active in separate dev, staging, and prod tenants in the same month counts as three MAUs), while [Cognito's MAU triggers](https://aws.amazon.com/cognito/faqs/) include token refresh, sign-out, and even an admin reading a user, so persistent-session apps are always counted. Others bill per connection (WorkOS), and at least one bills on **[MRU](https://clerk.com/glossary.md#monthly-retained-users-mrus)** (monthly _retained_ user — Clerk's model, which [excludes same-day churners and counts users who return 24+ hours after signup](https://clerk.com/changelog/2026-02-05-new-plans-more-value.md)). Because MRU and MAU count different populations, and because connection-based and user-based models scale differently, you cannot compare a single per-user number across vendors. **What "good" looks like.** A transparent, predictable model; a free tier generous enough to validate; and enterprise features that aren't gated behind punitive jumps. Watch for the **"SSO tax"** (the most common pricing red flag): the practice of gating SSO behind a large enterprise tier. The community-maintained [sso.tax](https://sso.tax/) catalog (backed by the [`sso-wall-of-shame`](https://github.com/robchahin/sso-wall-of-shame) dataset) computes markup as (SSO price − base price) ÷ base price × 100 and lists vendors charging multiples — Railway about 9,900%, Coursera about 2,400%, GitHub about 425%. **Questions to ask:** - Is the model per-MAU, per-MRU, per-user, per-connection, or flat — and how does that map to _your_ usage? - How generous is the free tier, and what triggers a billable user? - Are SSO, SCIM, MFA, or compliance gated behind large tier jumps ("SSO tax")? - Model the cost at 2× your projected scale, not today's. ### 12. Scalability, reliability, and performance **What it is.** Uptime/SLA commitments, public status history, rate limits, latency, and multi-region/edge support. **Why it matters.** Authentication is on the critical path of every request: if auth is down, your app is down. A contractual SLA matters for your own uptime commitments — and many providers only offer one on their enterprise tier. **What "good" looks like.** A published, contractual uptime SLA (99.9% or better), a transparent public status page with history, and documented rate limits and multi-region support. Check _which tier_ the SLA applies to — a "99.99%" headline often means "on Enterprise." **Questions to ask:** - Is there a contractual SLA, and on which plan? - Is there a public status page with incident history? - What are the rate limits, and are they sufficient for your peaks? - Is multi-region or edge support available if you need low latency globally? ### 13. Data ownership, portability, and vendor lock-in **What it is.** Whether you can export your users _and their password hashes_, the documented migration paths in and out, the use of standards-based tokens, and how hard it would be to leave. **Why it matters.** Lock-in is the risk that turns a bad fit into a permanent one. The single most important portability question is **password-hash export**: if you can't export hashes, leaving means forcing every user to reset their password — a migration that bleeds users. The hash-export story varies sharply by provider (see the [hash-export matrix in Part 3](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist-3.md#migration-considerations-and-the-hash-export-matrix)). **What "good" looks like.** Self-service export of users _and_ password hashes in standard formats, documented migration tooling, and standards-based tokens (OIDC/JWT) so downstream systems don't depend on a proprietary format. **Questions to ask:** - Can you export user records _and_ password hashes yourself, without a support ticket? - In what format are hashes stored, and is it a standard one (bcrypt, argon2, scrypt)? - Is there documented tooling for migrating in and out? - Are tokens standards-based (OIDC/JWT) so integrations are portable? ### 14. Extensibility, integrations, and support **What it is.** [Webhooks](https://clerk.com/glossary.md#webhook), a real backend/management API, custom claims and JWT templates, user metadata, and a healthy integration ecosystem — plus support tiers, response-time SLAs, community, and professional services. **Why it matters.** No provider does everything; extensibility is how you cover the gaps. Webhooks and a management API let you sync identity into your own systems and automate lifecycle. Watch for **disruptive deprecations** in the extensibility surface — for example, [Auth0's Rules and Hooks reach end-of-life on November 18, 2026](https://auth0.com/docs/troubleshoot/product-lifecycle/deprecations-and-migrations) (read-only since November 18, 2024), forcing a rewrite to Actions, where some functionality such as automatic account linking lacks a direct drop-in equivalent. **What "good" looks like.** Rich, reliable webhooks; a complete management API; custom claims/JWT templates; user/organization metadata; and a support model (with SLAs) that matches your needs. A stable extensibility surface that doesn't churn is itself a feature. **Questions to ask:** - Are there reliable webhooks and a complete backend/management API? - Can you add custom claims or JWT templates and store metadata? - What support tiers and response SLAs exist, and what's community-only? - Are there any disruptive deprecations on the roadmap? ### 15. Authentication for AI agents (MCP) — an emerging dimension **What it is.** Whether the provider can act as a first-party **OAuth authorization server for the Model Context Protocol (MCP)** — the open standard for connecting AI assistants and agents to external tools and data. A provider "supports MCP" in the auth-relevant sense when it can **issue scoped, user-consented OAuth tokens to a registered agent** — with a [consent screen](https://clerk.com/glossary.md#consent-screen) and [dynamic client registration](https://clerk.com/glossary.md#dynamic-client-registration) (DCR) under [OAuth 2.1 / RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591) — so an AI agent can act on a user's behalf. Adjacent agent-auth capabilities include a **token vault** / on-behalf-of token exchange (calling third-party APIs as the user), and asynchronous or step-up authorization. **Why it matters.** As AI agents begin to act for users, the same OAuth machinery that protects your app has to protect agent access too. For teams building agentic products, this is becoming a real evaluation axis. It's also where vendor claims need the most care: an **MCP _authorization_ server** (agent auth, scored here) is a different thing from a **developer-tooling MCP server** (which only feeds SDK snippets to AI coding assistants — a docs/DX aid from dimension 10). Many vendors ship the latter; fewer ship the former. **What "good" looks like.** A **GA, documented, first-party MCP authorization server** with a consent screen and DCR, ideally backed by broader agent-auth tooling (a token vault / on-behalf-of token exchange, and async authorization). This dimension is new and moving fast; verify GA status and scope before relying on any provider's claim. **Questions to ask:** - Can it issue scoped, user-consented OAuth tokens to a registered agent? - Does it support dynamic client registration (RFC 7591) or a documented successor? - Are the OAuth scopes limited to a built-in set, or can you request custom scopes? - Is there a token vault or on-behalf-of exchange for calling third-party APIs as the user? - Is the capability **GA**, or beta / DIY / only available through a separate service? ## The weighted evaluation checklist The 15 dimensions become an evaluation tool when you turn them into a scorecard and weight it for your situation. This section gives you a paste-able checklist, five ready-made weighting profiles, and the rule for turning scores into a decision. ### Copy-and-use checklist Copy this list into your own evaluation doc. For each candidate provider, answer each question with evidence (a link to the vendor's docs, pricing, or changelog), then assign a 1–10 score per dimension. The full question set for each dimension is in the dimension write-ups (dimensions 1–7 in [Part 1](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist.md), 8–15 above); these are the single highest-signal questions: - [ ] **Auth methods:** Are passkeys and MFA first-class and enforceable, with breach detection? - [ ] **Enterprise SSO:** Are SAML and OIDC supported for any IdP, and how is each connection priced? - [ ] **SCIM:** Is SCIM native, and does deprovisioning revoke sessions immediately? - [ ] **B2B orgs/RBAC:** Are organizations, roles, and permissions native primitives in the token? - [ ] **Security:** What automated attack protection exists, and what is the incident history? - [ ] **Compliance:** Are the certifications you need held on the plan you'll actually buy? - [ ] **Sessions:** Are tokens short-lived with rotation, and how fast is revocation? - [ ] **Developer experience:** Is there a current first-party SDK for your exact framework? - [ ] **UI:** Are there prebuilt components, headless hooks, or both — and can you stay on your domain? - [ ] **Documentation:** Do the quickstarts work on your framework version, unmodified? - [ ] **Pricing/TCO:** What triggers a billable user, and what's the cost at 2× your scale? - [ ] **Reliability:** Is there a contractual SLA, and on which plan? - [ ] **Lock-in:** Can you self-export users _and_ password hashes in a standard format? - [ ] **Extensibility:** Are there reliable webhooks, a management API, and custom claims? - [ ] **Agent auth (MCP):** Is there a GA first-party MCP authorization server if you're building agents? ### Weighting profiles for common situations The same scores rank differently depending on what you weight. Below are five profiles. Each lists the dimensions it weights most and least, and the best-fit that emerges — recomputed from the scorecard later in this article. Pick the closest, or build your own weights. **Profile A — Early-stage / consumer B2C app.** Weight highest: developer experience, auth methods, UI, pricing/free-tier, lock-in, docs. Weight lowest: enterprise SSO, SCIM, organizations, compliance, SLA, agent auth. **Best fit:** **Clerk** leads, with **Supabase** and **Firebase** as strong budget/bundled alternatives (especially if you want auth and a database together, or the lowest per-user cost). WorkOS also scores well across the board but is built for enterprise readiness, not consumer auth (hosted-only passkeys, no native-mobile SDKs). **Profile B — B2B SaaS product team going upmarket.** Weight highest: organizations/RBAC, developer experience, auth methods, UI, enterprise SSO, SCIM, sessions. Roughly even elsewhere. **Best fit:** **Clerk narrowly**, because it scores strongly on _both_ full end-user auth (DX, UI, methods) and enterprise readiness (orgs, SSO, SCIM). **WorkOS** finishes a hair behind — and pulls _ahead_ in the narrower case where you already have end-user auth and only need to bolt on SSO/SCIM, thanks to its hosted Admin Portal and per-connection model. **Auth0** is close behind both. **Profile C — Regulated / enterprise.** Weight highest: compliance, security, enterprise SSO, SCIM, sessions, SLA, support. Weight lowest: UI, pricing, lock-in. **Best fit:** **Genuinely contested.** **Auth0** and **AWS Cognito** lead on raw compliance breadth (both add ISO 27001 and FedRAMP, which the others don't), while **WorkOS** leads on enterprise provisioning depth (SSO and SCIM at 10/10). **Clerk** fits teams whose requirements stop at **SOC 2 Type II + HIPAA** — it does **not** hold ISO 27001 or FedRAMP, an honest ceiling for the most heavily regulated buyers. **Profile D — Internal tools / "add SSO to an existing app."** Weight highest: enterprise SSO, SCIM, security, provisioning, SLA. Weight lowest: UI, consumer auth methods, agent auth. **Best fit:** **WorkOS**, decisively — its 10/10 SSO and SCIM plus the self-service Admin Portal are purpose-built for bolting enterprise SSO onto an app that already handles its own user auth. (This is also Okta Workforce territory; see the CIAM vs. workforce IAM question in the [Part 1 FAQ](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist.md#frequently-asked-questions).) **Profile E — Building AI-agent / agentic products.** Weight highest: agent auth (MCP), developer experience, auth methods, session/token, extensibility/API. Weight lowest: SCIM, UI, compliance, SLA. **Best fit:** **Contested between Auth0 and Clerk.** **Auth0** leads the agent-auth dimension itself with the broadest suite (Token Vault for on-behalf-of token exchange, async/CIBA authorization, and FGA for RAG). **Clerk** leads the surrounding dimensions an agent builder also relies on — developer experience, the cleanest first-party MCP authorization server, and low lock-in — so it edges ahead on most weightings that don't make raw agent-auth breadth dominate everything else. **WorkOS** (open `auth.md` protocol + Pipes MCP) and **Supabase** (agent-as-user with row-level security) are close behind. ### How to turn scores into a decision 1. **Compute the weighted sum** for each candidate: Σ (weightᵢ × scoreᵢ). This narrows the field to a shortlist of two or three. 2. **Apply the red-flag veto layer** (detailed in [Part 3](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist-3.md#red-flags-to-watch-for)). A single dealbreaker — no hash export, a missing required certification, a stale SDK, a disruptive deprecation — can knock out a high-scoring candidate. 3. **Run a proof-of-concept** with your top one or two: wire up a real sign-in flow, test the migration-in path, and model the cost at 2× your projected scale. Do not accept any single ranking — including this article's scorecard — without re-weighting it for your own requirements. That re-weighting _is_ the evaluation. ## How the major authentication providers compare (evaluation results) These are the results of applying the framework, using the **hybrid** approach (numeric scores plus sourced notes) as of **June 2026**. Re-verify volatile cells — pricing, free tiers, and feature GA dates — against the linked primary sources before you rely on them. ### Scorecard: providers × dimensions Scores are 1–10, requirement-relative (10 = best-in-class on that dimension). There is **no overall-total column** by design: on a raw unweighted basis the top providers are statistically tied, so a single number would mislead. The recommendation emerges only after you apply the weighting profiles above. Each score's rationale appears in the [provider profiles in Part 3](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist-3.md#provider-profiles), with its primary source linked inline. | # | Dimension | Clerk | Auth0 | WorkOS | Firebase | Supabase | Cognito | | -- | --------------------------------- | :---: | :---: | :----: | :------: | :------: | :-----: | | 1 | Auth methods & passwordless | 9 | 9 | 7 | 8 | 8 | 7 | | 2 | Enterprise SSO (SAML/OIDC/EASIE) | 8 | 9 | 10 | 6 | 5 | 5 | | 3 | Directory Sync & SCIM | 9 | 8 | 10 | 1 | 1 | 2 | | 4 | B2B orgs, multi-tenancy & RBAC | 9 | 9 | 9 | 4 | 4 | 4 | | 5 | Security & incident history | 8 | 5 | 8 | 8 | 7 | 6 | | 6 | Compliance & certifications | 6 | 10 | 7 | 8 | 7 | 10 | | 7 | Session & token management | 9 | 9 | 9 | 8 | 9 | 7 | | 8 | Developer experience (SDKs) | 9 | 9 | 8 | 7 | 8 | 5 | | 9 | UI components & customization | 9 | 8 | 8 | 7 | 5 | 5 | | 10 | Documentation quality | 9 | 9 | 9 | 8 | 8 | 6 | | 11 | Pricing & total cost of ownership | 7 | 5 | 8 | 8 | 8 | 7 | | 12 | Scalability & reliability | 8 | 9 | 9 | 9 | 6 | 8 | | 13 | Data ownership & lock-in | 9 | 5 | 8 | 4 | 9 | 3 | | 14 | Extensibility & support | 8 | 7 | 8 | 7 | 8 | 7 | | 15 | Auth for AI agents (MCP) | 8 | 9 | 8 | 3 | 7 | 4 | **Cross-provider read (for honest framing, not a ranking).** Clerk and WorkOS sit neck-and-neck at the top, with Auth0 close behind; Firebase and Supabase form a strong consumer/portability tier; Cognito trails on B2B, SCIM, DX, and lock-in but leads (with Auth0) on compliance. On the newest dimension — auth for AI agents — **Auth0 leads**, with Clerk and WorkOS tied just behind and Supabase close. **No provider wins every dimension**, which is the entire point of weighting the scores to your needs. ### Capability presence at a glance A binary view of the capabilities that most often decide a shortlist. "Partial" means available with a caveat — a required upgrade, hosted-only, beta, or a specific tier — noted in the [provider profile in Part 3](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist-3.md#provider-profiles). | Capability | Clerk | Auth0 | WorkOS | Firebase | Supabase | Cognito | | ----------------------------------------- | :---: | :-------------: | :----: | :------: | :-------: | :-----------: | | Native B2B organizations & RBAC | Yes | Yes | Yes | No | No | No | | Native SCIM directory sync | Yes | Yes | Yes | No | No | No | | Enterprise SAML SSO | Yes | Yes | Yes | GCIP | SAML only | pool-level | | First-party prebuilt UI components | Yes | Universal Login | hosted | beta | No | Managed Login | | First-party native mobile SDKs | Yes | Yes | No | Yes | community | Amplify | | Open-source / self-hostable | No | No | No | No | Yes | No | | First-party MCP authorization server (GA) | Yes | Yes | Yes | No | Yes | No | ## Frequently asked questions ## FAQ ### Why should developer experience (DX) be a heavily weighted dimension? Developer experience directly impacts time-to-market and ongoing maintenance costs. High-quality SDKs, framework currency, and comprehensive documentation mean your team spends less time fighting the integration and more time building core product features. ### How does pricing complexity affect the total cost of ownership? Many providers use tiered pricing based on monthly active users (MAUs), but complexity arises from hidden fees for enterprise SSO, MFA text messages, or B2B organization limits. A transparent pricing model prevents unexpected spikes in cost as your application scales. ### What is MCP and why is it relevant for authentication? The Model Context Protocol (MCP) is an emerging standard for AI agents to securely interact with external systems. Evaluating a provider's support for AI agent authentication ensures your infrastructure is prepared for next-generation, AI-driven application architectures. ## Conclusion Evaluating an authentication provider goes far beyond simple feature parity. By examining the developer experience, pricing, scalability, and extensibility—and applying customized weightings to these dimensions—you can generate a scorecard that reflects your unique priorities. The comparison matrix provided here offers a strong starting point for narrowing down your options. In [Part 3](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist-3.md), we will dive into detailed profiles for each of the six evaluated providers, highlighting their strengths and ideal use cases. We will also explore critical red flags, typical implementation timelines, and provide a comprehensive decision tree to help you make your final choice. ## 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** (you are here) 3. [How to Evaluate Authentication Providers: A Developer’s Checklist - Part 3](https://clerk.com/articles/how-to-evaluate-authentication-providers-a-developer-s-checklist-3.md)