Auth Providers 2026: Clerk vs Auth.js vs WorkOS vs Supabase

Authentication looks finished after a weekend: a login form, a password hash, a session cookie. The unfinished part arrives later, as password-reset abuse, a customer asking for single sign-on, or an OAuth provider changing a field name. This article compares the five providers most JavaScript teams shortlist in 2026: Clerk, Auth.js, WorkOS, Supabase Auth, and Better Auth. It covers what each does, what it costs at three sizes, where lock-in hides, and which team profile each one fits.

Why most teams should not write auth from scratch

Authentication answers one question: is this request really from the person it claims to come from? That sounds small, but a correct answer involves several separate systems that all have to be right at once. Think of an airport. Checking a passport at the gate is the easy part. The hard part is the badge office, the lost-badge process, the staff entrance, and the guard who notices a forged badge.

Three public documents define most of that surrounding machinery. They are worth knowing because every provider below is, in effect, an implementation of them.

Password rules. The U.S. National Institute of Standards and Technology (NIST) revised its digital identity guidance in SP 800-63B-4. For a password used as the only factor, it requires at least 15 characters. A password used only as one part of multi-factor authentication may be shorter, but not under eight characters. The document says services must not impose composition rules such as "one symbol and one capital letter," and must not force periodic password changes unless there is evidence of compromise. It also requires checking new passwords against a blocklist of known compromised ones, and allowing password managers and pasting (NIST SP 800-63B-4). It is worth checking any login form you have shipped against that list.

Session rules. After login, the server hands the browser a session identifier, a bit like a coat-check ticket. The Open Worldwide Application Security Project (OWASP) recommends at least 64 bits of entropy (randomness) for that identifier, generated by a cryptographically secure random number generator. It also recommends the Secure and HttpOnly cookie attributes, an explicit SameSite setting, a fresh identifier after every login to block session fixation, and server-enforced idle and absolute timeouts (OWASP Session Management Cheat Sheet). Each item is a one-line setting that is easy to forget.

Delegation rules. "Sign in with Google" is an application of OAuth 2.0, published as RFC 6749 in October 2012. The standard defines four roles (resource owner, client, authorization server, resource server) and four grant types: authorization code, implicit, resource owner password credentials, and client credentials (RFC 6749). Choosing the wrong flow, or skipping a check on the redirect, is how many OAuth bugs happen.

NIST's current guidance prohibits the two password rules most sign-up forms still enforce: mandatory character mixes and forced periodic rotation.

None of this is exotic, but the list is long, and an error in any item can become a security incident. That is the real argument for adopting a provider, and it holds even for strong engineering teams. If you want the underlying mechanics before choosing a vendor, our guide to web auth patterns in 2026 walks through sessions, tokens, and OAuth flows in detail.

When outsourcing makes sense and when it does not

Outsource authentication when:

• A small team needs to spend its time on the product, not on login flows.
• You need social login, multi-factor authentication (MFA), or magic links (a sign-in link sent by email) soon.
• Business customers will eventually ask for single sign-on (SSO), which lets employees log in through their company's identity system.
• A compliance report such as SOC 2 will be requested during sales.

Keep authentication in-house when:

• Legal or data-sovereignty rules rule out third-party SaaS.
• Authentication is the product you sell.
• You expect millions of monthly users and per-user pricing would dominate your infrastructure bill.

"In-house" does not have to mean "from scratch." A library such as Auth.js or Better Auth gives you vetted protocol code while you keep the data and the user interface. That middle path is why the open-source options appear in this comparison at all.

The five contenders at a glance

The five options split along two lines: managed versus self-hosted, and consumer-focused versus enterprise-focused.

Tool	Type	Strongest at	Pricing model (checked October 2026)
Clerk	Managed service	Hosted UI, user dashboard, organizations	Free to 50,000 monthly retained users, then Pro from $25/month plus per-user overage
Auth.js	Open-source library	Protocol layer for Next.js and other frameworks	Free; you host and operate everything
WorkOS	Managed service	Enterprise SSO, directory sync, audit logs	First 1 million MAU free for AuthKit; $125 per SSO connection
Supabase Auth	Bundled with a backend	Row-level security with Postgres	50,000 MAU on the Free plan, 100,000 on Pro (from $25/month)
Better Auth	Open-source library	Framework-agnostic TypeScript auth with plugins	Free; you host and operate everything

The pattern holds across the table. Managed services trade money for time and for a maintained security surface. Open-source libraries trade time for control and for zero per-user cost. WorkOS occupies a separate niche, and Supabase Auth makes sense mostly if the rest of your backend is already Supabase.

A note on the numbers. Pricing pages change, and vendors count users differently. Clerk bills on monthly retained users (MRUs), which the company distinguishes from monthly active users (MAUs). WorkOS and Supabase use MAU. Treat any cross-vendor price comparison as an estimate and rerun it against current vendor pages before committing.

Clerk: the polished managed default

Clerk sells hosted authentication with ready-made interface components. You embed a sign-in form, a sign-up form, and a user-profile panel, and Clerk handles the rest, including the dashboard where support staff can look up users.

What it does well

• Interface and dashboard. Prebuilt sign-in, sign-up, and account screens mean a working login in an afternoon. The dashboard lets non-engineers inspect and manage users.
• Organizations. Roles and permissions are defined once at the application level and apply across all organizations. Default admin and member roles cover common cases, and custom roles add finer control. Verified domains let people with a matching email domain join automatically, or request to join with admin approval (Clerk Organizations documentation).
• Enterprise connections. Clerk supports enterprise connections over SAML or OIDC, so a customer's IT team can control sign-in through their own identity provider (same documentation page).

What to watch

• Per-user pricing. The free Hobby plan covers up to 50,000 monthly retained users and three dashboard seats. Beyond that, Pro costs $25 per month billed monthly ($20 billed annually), with overage of $0.02 per user for users 50,001 to 100,000, $0.018 per user from 100,001 to 1,000,000, and lower rates above that (Clerk pricing).
• Add-ons. MFA is included in Pro but not in Hobby. The Enhanced B2B add-on (custom roles, verified domains, unlimited organization members) is $100 per month ($85 billed annually). The first enterprise SSO connection is included on Pro, and additional connections are listed at $75 per month each. Directory Sync billing for extra connections starts January 1, 2027.
• Dependence. Because Clerk stores your users and sessions, leaving means exporting user data and rebuilding flows. More on that in the migration section.

Clerk fits consumer and prosumer products, indie founders who want to ship quickly, and teams that would rather pay than maintain login code.

Auth.js: the open-source standard, now under new ownership

Auth.js, formerly NextAuth.js, is a library that implements the protocol side of sign-in: OAuth and OpenID Connect flows, session handling, and database adapters. It is free, it runs inside your own application, and you decide where data lives.

The most important recent fact is about who maintains it. On September 26, 2025, the Auth.js team announced in a GitHub discussion that the project would be maintained by the Better Auth team. The post cited the project's limited scope and a slowdown in development over the past year, said security and urgent fixes would continue, and said existing users could keep using Auth.js. For new projects, the team recommended Better Auth (Auth.js announcement, GitHub discussion #13252). The Auth.js site now carries the notice "The Auth.js project is now part of Better Auth" (authjs.dev).

That changes how to read older advice. Older comparisons described Auth.js as the default open-source choice with a roadmap of new features. In late 2026 the accurate description is a mature, widely deployed library in maintenance mode, with a sibling project taking the active development.

What it does well

• Simplified v5 API. Version 5 introduced a single auth() function that replaces separate helpers for server components, route handlers, and middleware. Configuration lives in one root auth.ts file, environment variables use the AUTH_ prefix, and Next.js 14 or later is required (Auth.js migration guide).
• Edge awareness. The library uses standard Web APIs and can run on edge runtimes. Database sessions work on the edge only if the database and its adapter do, so the docs recommend splitting configuration into an edge-safe file and a full one.
• No per-user cost. The software is free. You pay only for hosting and for your own time.

What to watch

• You own the product around it. Auth.js handles the protocol layer. The account settings page, password reset emails, MFA enrollment, and abuse protection are your responsibility.
• Maintenance posture. Security fixes continue, but feature development is not promised. If you start a project today and want active development, the Better Auth route is the one its maintainers recommend.

For TypeScript-heavy stacks, our TypeScript guide for beginners covers the type-safety background that makes these libraries pleasant to use.

Better Auth: the open-source option with momentum

Better Auth describes itself as a framework-agnostic authentication and authorization framework for TypeScript. Its documentation highlights two-factor authentication, passkeys, multi-tenancy, multi-session support, and enterprise options such as SSO, all delivered through a plugin system (Better Auth introduction).

Think of the plugin approach as a power strip versus a hard-wired circuit. The core handles email-and-password plus social sign-in, and each additional capability is something you plug in only when needed. The benefit is a small surface for simple apps. The cost is that you must read each plugin's documentation and keep versions aligned.

Why teams pick it

• Not tied to one framework. It targets TypeScript broadly, which matters if your stack is not Next.js.
• Same team as Auth.js. Because the same team now maintains both, the Auth.js team recommends it for new projects.
• Data stays in your database. As with Auth.js, you operate it, so you control where user records live.

What to weigh

• Younger project. It has less accumulated production history and fewer third-party tutorials than the library it is succeeding.
• You carry the operational load. Running authentication yourself means you own patching, monitoring, and incident response. No SOC 2 report comes with a library you host.
• Enterprise SSO takes extra work. Even with an SSO plugin, supporting a large customer's identity provider is usually more labor than buying a managed connection.

WorkOS: the enterprise specialist

WorkOS exists for the moment a sales call includes the sentence "does your product support SSO?" Its products cover enterprise single sign-on, directory sync (automatic user provisioning and removal from a customer's directory), and audit logs. AuthKit, its user-management layer, handles email and password, social login, magic auth, MFA, and SSO behind a hosted interface, with email verification on by default and bot detection against brute-force attempts (WorkOS AuthKit overview).

The pricing model is the interesting part. AuthKit is free for the first one million monthly active users, then $2,500 per month for each additional million. SSO and Directory Sync are listed at $125 per connection for the first 15 connections, with volume discounts beyond that. Audit-log streaming is $125 per month per SIEM connection, and retention is $99 per month per million events. A custom domain is $99 per month (WorkOS pricing).

Why the model is distinctive. Most vendors charge for every user. WorkOS charges mainly when a business customer actually needs enterprise features, which is also when that customer is likely paying you enough to cover the cost. For a business-to-business product with a few large accounts, that alignment is useful.

What to weigh

• Per-connection costs add up. At the listed $125 each, ten SSO customers adds $1,250 to the bill. Companies often fold that cost into the price of their enterprise plan.
• Scope. If you only need basic consumer login, a larger enterprise-oriented product is more than you need.
• Compliance. WorkOS states that it is SOC 2 Type 2 certified and GDPR and CCPA compliant (WorkOS security).

Supabase Auth: bundled with the backend

Supabase Auth is the authentication layer inside Supabase, the Postgres-based backend platform. It issues JSON Web Tokens (JWTs, signed tokens that carry the user's identity), stores user data in a dedicated schema in your project's Postgres database, and works with Postgres Row Level Security (RLS) to decide which rows each user may read or write (Supabase Auth documentation).

Row Level Security is the feature that makes the bundle compelling. Imagine a filing cabinet where each drawer opens only for the person whose name is on the label. With RLS, the database itself enforces that rule, using the logged-in user's token, so a bug in your application code is less likely to expose someone else's data.

What it supports. The documentation lists password, magic link, email one-time passwords, social login, and phone authentication through Twilio, MessageBird, or Vonage. Users can add a second factor using TOTP or phone, and enterprise SSO uses SAML 2.0. Custom OAuth2 or OIDC providers can be added.

Pricing. The Free plan includes 50,000 monthly active users for authentication. Pro starts at $25 per month with 100,000 included and $0.00325 per additional user. Team starts at $599 per month with the same user allowance and overage. SAML SSO is not included on Free, and Pro includes 50 SSO users before charging $0.015 per user (Supabase pricing).

Compliance. Supabase states that it is SOC 2 Type 2 compliant and HIPAA compliant, with the HIPAA statement conditioned on signing a business associate agreement and meeting your own obligations under a shared-responsibility model (Supabase security).

What to weigh. You build sign-in screens yourself or use community components. Your authentication is tied to Supabase as a platform. And the dedicated enterprise features of WorkOS are not matched by Supabase's SSO offering for sales-heavy business-to-business products.

What each costs at three sizes

The table below uses list prices from the vendor pages cited above, checked in October 2026. The figures are our own arithmetic from those published rates, not quotes from the vendors. They exclude taxes, discounts, SMS charges, hosting for self-run libraries, and any compute or storage charges for Supabase.

Monthly users	Clerk (Pro)	WorkOS AuthKit	Supabase Auth (Pro)	Auth.js or Better Auth
10,000	$25	$0	$25 (base plan)	$0 plus hosting
150,000	$1,925	$0	$190	$0 plus hosting
500,000	$8,225	$0	$1,325	$0 plus hosting
1,000,000	$17,225	$0	$2,950	$0 plus hosting

How the Clerk figures work. Pro includes the first 50,000 monthly retained users. At 150,000, the overage is 50,000 users at $0.02 ($1,000) plus 50,000 at $0.018 ($900), added to the $25 base, for $1,925. At 500,000 it is $25 plus $1,000 plus 400,000 at $0.018 ($7,200), or $8,225. At one million it is $25 plus $1,000 plus 900,000 at $0.018 ($16,200), or $17,225.

How the Supabase figures work. Pro includes 100,000 users at $25. At 150,000, 50,000 extra users at $0.00325 add $162.50, so about $190 with rounding. At 500,000 it is $25 plus 400,000 at $0.00325 ($1,300), or $1,325. At one million it is $25 plus 900,000 at $0.00325 ($2,925), or $2,950.

How the WorkOS figure works. AuthKit is free through one million MAU, so the user-count line is $0 in this range. Enterprise connections are extra: ten SSO customers at the listed $125 each is $1,250 on top.

Two cautions apply. First, a free tier is not free if it excludes the feature you need. Clerk's Hobby plan has no MFA, and Supabase's Free plan has no SAML SSO. Second, the open-source column is $0 only for software. It still costs engineering hours, and at some scale those hours exceed a vendor invoice. A fair comparison puts a vendor invoice, such as $8,225 per month ($98,700 per year) for Clerk at half a million users, next to the engineering time you would spend patching, monitoring, and supporting your own deployment.

Enterprise SSO changes the decision

Enterprise customers do not want another password. They want their employees to sign in through the company's identity provider, such as Okta or Microsoft Entra ID, so IT can switch off a departing employee's access in one place. That requirement typically shows up during a customer's security review.

Two protocols cover most of it. SAML is the older, XML-based standard that most large companies already run. OpenID Connect (OIDC) is a newer layer built on OAuth 2.0. Supporting either one means mapping each customer's identity provider into your user model and keeping those mappings alive as their IT team changes settings.

Directory sync is the companion feature. Single sign-on controls who can log in. Directory sync controls who exists in your product: when HR removes someone from the company directory, their account in your app should disappear, too.

Capability	Clerk	WorkOS	Supabase Auth	Auth.js / Better Auth
SAML or OIDC enterprise sign-in	Yes, one connection included on Pro	Yes, core product	SAML 2.0, 50 users included on Pro	Better Auth documents an SSO plugin; you operate it
Directory sync	Listed, with billing for extra connections from January 1, 2027	Yes, core product	Not listed on the pages reviewed	Not provided by Auth.js; verify for Better Auth
Audit logs	Not covered on the pages reviewed	Yes, with retention and streaming	Not covered on the pages reviewed	You build them

A realistic split follows from that table. If enterprise customers are a small share of your revenue, bundled SSO from your main provider is usually enough. If enterprise deals are the business, a specialist such as WorkOS is more likely to have the edge-case handling that deals require, and its per-connection pricing tracks revenue.

Passkeys and the slow end of passwords

Passkeys are sign-in credentials based on FIDO standards. A passkey lives on a phone, computer, or hardware key, and the user unlocks it with a fingerprint, face scan, or device PIN. Technically, passkeys build on FIDO2, which combines WebAuthn (the browser interface) with CTAP (the protocol between a device and an authenticator). They use public-key cryptography, so the server stores no shared secret that an attacker could steal in a breach (FIDO Alliance passkeys overview).

The practical difference is easiest to see with a house key analogy. A password is like a spare key hidden under the mat: anyone who learns where it is can use it, and a convincing fake website can ask for it. A passkey is more like a key that only turns in your own front door. A phishing site at the wrong address cannot trigger it, because the credential is bound to the real site's domain.

FIDO distinguishes synced passkeys, stored with a provider such as a platform credential manager and described as end-to-end encrypted, from device-bound passkeys that never leave one device. NIST's guidance is consistent with that direction. It requires verifiers to offer at least one phishing-resistant option at the second assurance level and names WebAuthn as an example of verifier name binding, which is what makes the credential site-specific (NIST SP 800-63B-4). For a plain-language walkthrough, see our explainers on how passkeys replace passwords and how passkeys sync across devices safely.

On adoption, a survey commissioned by the FIDO Alliance in 2024 found that 53% of people had enabled passkeys on at least one account, and 22% on every account where they could. Because the sponsor is the standards body that promotes passkeys, read the figure as an indication of momentum rather than as a neutral market measurement.

For provider choice, the lesson is modest. Passkey support is now a checkbox feature to verify, not a differentiator to chase. Confirm that your candidate supports it, then test the actual sign-in and recovery flow on the devices your users own.

Authentication for AI agents

A newer question is how software agents act on a user's behalf. An assistant that books travel or reads a mailbox needs credentials, and handing it the user's password would defeat the purpose of everything above.

Three patterns are in use, and none is settled:

1. Service accounts. The agent has its own identity, separate from any user, with narrow permissions.
2. Delegated OAuth scopes. The user grants specific, revocable permissions to the agent, the same mechanism used when you connect a calendar to a scheduling app.
3. Per-action approval. The agent proposes a significant action and a human confirms it before it runs.

None of the vendors reviewed here has made agent authorization its defining feature, so do not choose a provider on that basis yet. The more useful habit is to design your permissions model so that a request carries a scope, such as "read calendar" or "send email," rather than blanket user access. That structure will transfer to whichever agent standard emerges. For a broader look at where autonomous systems fit, see our analysis of AI agents versus traditional automation.

Rate limiting and usage metering, which matter more for AI products, sit downstream of authentication. Our explainer on how rate limiting protects APIs covers that layer.

What migration and lock-in look like in practice

Vendor demos make switching look like an export button. In practice, some things move easily and others do not. This section is based on how the systems work rather than on a measured study, so treat the time estimates as planning heuristics.

Item	Usually portable?	Why
Email addresses and profile fields	Yes	Plain data you can export
Social login links	Mostly	The provider's account identifier travels with the user, but you must re-link in the new system
Password hashes	Depends	Some providers export them, some do not; the hash format must be supported by the destination
Active sessions	No	Sessions are tied to the old system's keys, so users sign in again
MFA enrollments	Rarely	Secrets are often not exportable, so users re-enroll
Roles, organizations, metadata	Needs mapping	Each vendor models them differently
Webhooks and downstream integrations	No	Every consumer of the old events must be updated

The pattern behind the table is that identity data is portable, while trust artifacts such as sessions, second factors, and signing keys are not. A migration therefore forces a one-time re-login for all users, and the forced re-enrollment of MFA is the part most likely to generate support tickets.

Three habits reduce the cost of a future move. Keep your own users table keyed by your own identifier, and store the vendor's user ID as an attribute rather than as the primary key. Keep authorization rules (who can do what) in your code or database, not only in the vendor's metadata. And wrap vendor calls behind a thin internal module so the switch touches one folder instead of the whole codebase.

How to pick: decision rules by profile

These are starting points, not verdicts. Each assumes you have confirmed current pricing and feature availability.

• Solo founder or indie product, cost-sensitive. Better Auth, with Auth.js as a reasonable choice if you already run it. Free software, full control, and you accept the operational work.
• Funded consumer product that values speed and polish. Clerk. Hosted interface and dashboard save weeks, and per-user cost stays small through the free tier.
• Business-to-business product heading toward enterprise deals. A consumer-friendly provider for everyday login plus WorkOS for SSO and directory sync, or WorkOS AuthKit for both if you prefer a single vendor.
• Product already built on Supabase. Supabase Auth. Row Level Security with the user's token is the deciding feature.
• Large consumer base where per-user fees dominate. Self-hosted Better Auth or Auth.js, or a vendor with a high free allowance, after modeling cost at your actual scale.
• Strict data-sovereignty or regulatory limits. Self-hosted libraries, possibly alongside a self-hosted identity server for enterprise needs.

The framework you use also narrows the field. If you are choosing between full-stack options, our comparisons of Next.js and React and the Next.js 15 developer's guide show where authentication hooks into routing and server components, and our best web development tools roundup places these providers within the wider stack.

The takeaway

The choice among Clerk, Auth.js, WorkOS, Supabase Auth, and Better Auth is less about which is best than about which cost you prefer to pay: money, engineering time, or dependence on a platform. The most important change in 2026 is not a feature. Auth.js is now maintained by the Better Auth team, which makes Better Auth the open-source default for new projects and Auth.js a stable library you may already run. Price tables that predate that change, or that quote round numbers without arithmetic, are unreliable. Decide what you must own, model your costs at the size you expect to reach, and keep your own user identifiers so that a future move is an inconvenience instead of a rewrite.

Frequently asked questions

Q: Is writing your own authentication ever a good idea in 2026? A: Rarely. Standards such as NIST SP 800-63B-4 and the OWASP session guidance show how many details must be correct at once. The main exceptions are teams building an identity product, or teams under legal limits that rule out third-party services. Even then, a vetted open-source library is usually safer than custom code.

Q: Which of these providers publish compliance certifications? A: Supabase states SOC 2 Type 2 and HIPAA compliance (HIPAA requires a signed business associate agreement), and WorkOS states SOC 2 Type 2 certification plus GDPR and CCPA compliance. Clerk's pricing page lists a SOC 2 report as part of its Business plan, so check its trust documentation for the current scope. Libraries such as Auth.js and Better Auth carry no certification of their own; your hosting and operations are what get audited.

Q: Did the Better Auth and Auth.js announcement end Auth.js? A: No. The September 26, 2025 announcement said Auth.js would be maintained by the Better Auth team, with security and urgent fixes continuing and existing users free to keep using it. For new projects or major refreshes, the team recommended Better Auth.

Q: Can I combine several providers? A: Yes, and it is common in business-to-business products: one provider for everyday sign-in and WorkOS for enterprise SSO. The friction is at the user-record level, because the same person may exist in both systems. A single internal users table keyed by your own identifier solves most of it.

Q: How were the cost figures calculated? A: From the vendor pricing pages as of October 2026, using the arithmetic shown under the cost table, so you can redo it when prices change.

Q: Are passkeys ready to replace passwords? A: They are widely supported and phishing-resistant by design, but most services still offer passwords as a fallback. Plan for both: enable passkeys, keep a recovery path, and follow NIST's password rules for the credentials that remain.

Q: What should I check before committing to a managed provider? A: Confirm how the vendor defines a billable user, what happens when you exceed a free allowance, whether MFA and SSO are in your plan, how you export user data, and whether password hashes can leave. Those five answers predict most of the surprises.

Sources

• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management
• OWASP Session Management Cheat Sheet
• RFC 6749, The OAuth 2.0 Authorization Framework
• Clerk pricing and Clerk Organizations documentation
• WorkOS pricing, WorkOS AuthKit overview, and WorkOS security
• Supabase pricing, Supabase Auth documentation, and Supabase security
• Auth.js announcement, GitHub discussion #13252, Auth.js getting started, and Auth.js v5 migration guide
• Better Auth introduction
• FIDO Alliance, Passkeys

Pricing and feature details were read from the vendor pages above in October 2026 and may have changed since.