durable-auth

durable-auth vs the real auth products

Most of the time, one of the others is the right answer. This page is about the times it isn't.

An honest comparison, checked 19 October 2026

Where do your users live?

Feature lists move every quarter. The structural question doesn't: in a vendor's service, in a database you run, or in a Durable Object you already deploy. durable-auth only makes sense if the answer you want is the last one and you can live with passkeys and email as the only ways in.

Option Users live in Passkeys Public sign-up Social / SSO Orgs Hosted UI Free tier
durable-auth One Durable Object's SQLite, in your account The only way in Yes, gate it with allowSignup Neither, deliberately No No — you build the screens MIT; your Workers bill
Cloudflare Access Your identity provider; Access sits in front and hands the app a JWT WebAuthn as a second factor after the IdP (Independent MFA) No — deny by default, allowlist policies, every user a seat Yes — many IdPs, or an emailed one-time PIN Policy groups, not app tenants Yes Up to 50 users
Better Auth Your database (D1 natively since 1.5), with its schema Plugin, on SimpleWebAuthn Yes Yes — social providers, SSO plugin (OIDC, SAML) Organization plugin No — you build the screens MIT; your database bill
Clerk Clerk's service; @clerk/backend runs on Workers Pro and Business plans, not the free one Yes Yes — SSO from Pro Yes, on every plan Yes — components and Account Portal 50,000 retained users per app
Auth0 Auth0's service Yes, including the free plan Yes Yes — social, and one enterprise connection free Organizations (5 free) Yes — Universal Login 25,000 monthly active users
Lucia (deprecated) Deprecated in March 2025. The site now holds what you need to replace Lucia v3 and points to its author's Auth Book, a guide to implementing auth yourself, which includes a passkey-plus-email-code example close to this library's design.

Checked against each project's own docs and pricing pages on 19 October 2026 (sources below). These products move fast and this page is written by someone with an obvious interest — if a cell is wrong or out of date, open an issue and it gets fixed. Plan limits in particular change; follow the links.

Which one should you use?

Use Cloudflare Access if…

The people signing in are a team you can list: staff, contractors, a beta group. It's deny-by-default, it works in front of any app without code, it speaks to the identity provider you already have, and it's free up to 50 users. It's the wrong shape for an app strangers sign up to, because every user is a seat on an allowlist — which is why this library exists. (Its documented WebAuthn support is a second factor after the identity provider; a passkeys identity-provider type appears in the API reference, but not yet in a setup guide.)

Use Better Auth if…

You want a library rather than a vendor, and you need more than passkeys: email and password, social login, two-factor, organisations, SAML or OIDC SSO. It does all of that, it's MIT, its passkey plugin uses the same SimpleWebAuthn underneath, and since 1.5 it takes a D1 binding directly. The cost on Workers is a database schema and migrations to own, and the nodejs_compat flag. If you'll ever need organisations or SSO, start here rather than outgrowing durable-auth later.

Use Clerk or Auth0 if…

You'd rather pay than own sign-in. Both give you hosted, polished UI, social login, organisations, enterprise SSO, account management, compliance paperwork and a team on call — none of which durable-auth has, and some of which you will need the moment you sell to a company. Auth0's free plan includes passkeys and 25,000 monthly active users; Clerk's free plan covers 50,000 retained users per app, but passkeys need its Pro plan. The trade is that your users live in their service, and the bill grows with them.

Read the Auth Book if…

You want to understand what any of these do, or write your own. Lucia's author replaced the library with a guide, and it is the best free explanation of sessions, passkeys and email codes there is. Reading it is a good way to audit this library, too.

Use durable-auth if…

You're all-Cloudflare, your app is open to the public, and passkeys plus an optional recovery email are all the ways in you want. Then a Durable Object already gives you the hard part — one thing at a time, with its own SQLite — and what's left is the routes, the ceremonies and the caps. That's this package: no vendor, no database to provision, no schema to migrate by hand, and nothing in a dashboard.

What you give up

No organisations, roles or invitations. No social login, SSO or passwords. No hosted UI: you write the sign-in screen. No admin dashboard to look a user up in. Its maturity is one production app and a test suite, not years and a security team. The recovery email is the recovery factor, and the guess caps that protect codes can be spent by a stranger to pause recovery. And one Durable Object serves every account — plenty for thousands of active users, not a design for millions.

The full security model, including what it doesn't do

Checked against

Cloudflare Access

Better Auth

Clerk

  • Pricing — 50,000 retained users per app free; passkeys and SSO on Pro and above; organisations on every plan
  • Account Portal — hosted sign-in, sign-up and profile pages
  • @clerk/backend — built for V8 isolates including Workers

Auth0

Lucia