Build an Auth0 alternative

You can build an Auth0 alternative as users, a password or a magic link, and a session you can end. Auth0 is that product. The catalog line is “Sign in, stay signed in, sign out.”

The card lists $35 to $240 a month. Auth0’s pricing is the source for the note on the card. B2C Essentials is $35 a month through Professional at $240 a month, at 500 monthly active users. The card leaves out higher user tiers and Enterprise quotes. The first estimate is 12 hours. The verdict is “Login is a weekend”.

Last time I wrote about building a lemlist alternative. That was a regular post. This one is a teardown.

The public sources are Auth0’s session layers, Universal Login, single sign-on, database connections, cookies, the organizations post, the organization authentication scenario, and the IdP-initiated SAML warning. Where those pages stop, I call it a guess.

Build an Auth0 alternative from one session

The Auth0 page splits the work into three rows.

The first row is 12 hours. Users, a password or a magic link, and a session.

The second row is 4 days. Password reset, a session revoke from an admin list, user admin, and an audit log.

The third row is 3 months and up. SAML, social login, organizations, and an identity OS. The card’s non-goal leaves that directory out of v1.

If you tell an agent to “clone Auth0”, it aims at the third row. Copy the prompt, then pin it to the first one.

Store User, Credential, Session, and AuthEvent. The card names all four. A user is an email and a status. A credential is either a password hash or a one-time token hash, with an expiry on the token. A session is a row tied to that user, with a last-seen time and an idle limit. An auth event is a sign-in, a reset, or a revoke. The screen that lists those events is the 4-day row.

The audience is a developer who wants login for one app on infrastructure they run. The same v1 also stands in for Clerk and SuperTokens.

A vault of your own passwords is 1Password at $3.99 to $5.99 a month on annual billing, in Vibe code your own 1Password. An approve or a deny on a login request is Duo at $3 to $9 per user a month. The mail that carries a magic link is Postmark at $15 to $18 a month for a plan that starts at 10,000 emails, in Vibe code your own Postmark. This v1 is the session inside one app, Lumen.

The guardrail is the rule you paste into the prompt. Hash passwords and one-time tokens. Expire the magic link. Never log a credential or a raw token.

How does Auth0 keep you signed in

Noor runs Lumen, a client portal for one studio. On November 8, 2026 the clients are Ada at [email protected] and Ben at [email protected].

Ada signs up with a password. The row stores a hash. She signs in, the hash matches, and the server writes a session with a last-seen time. The cookie points at that row. The projects page reads it, sees the idle time has not passed, and renders. Sign out deletes the row. The next request finds no session.

Ben asks for a link instead. The server stores a hash of a random token, with an expiry, and the mail provider sends the link. The raw token is in the email. He opens it once, the hash matches, and a session is written. The same link a second time finds a spent hash and does not sign him in. If Ada leaves the tab past the idle limit, the next request treats the session as ended.

Auth0’s session layers name three sessions. The application session is Lumen’s cookie. The Auth0 session is a second cookie on their authorization server, which is how a later redirect skips the form. The third is the identity provider. Someone with a live Google or Facebook session may skip that provider’s password and still be asked before the profile is shared.

Universal Login is that server’s screen. The app redirects, Auth0 checks its cookie, and a missing cookie means the form runs and the cookie is created. The app gets an ID token and an access token. Their single sign-on page says a central domain shares that result, and native apps only get SSO through Universal Login.

The password is a database connection: an email, username, or phone number, plus a password or a passkey. The hosted store keeps a bcrypt hash. A custom connection is a login script Auth0 runs against a database it can reach. Lumen checks Ada’s hash locally, with no redirect. Their cookies page describes a cookie as a pointer to a record, or a signed value around a 4KB limit. Deleting the record revokes the pointer. The signed value has no row to delete. Lumen uses the pointer, so the 4-day screen is Noor deleting Ada’s row.

Organizations are the long row. The organizations post (October 9, 2026) calls one a tenant inside the Auth0 tenant: members, connections, metadata, and roles. A connection can be their database, Google Workspace, Okta, or Microsoft Entra ID. Pass an organization id or name and the form only offers that organization’s connections. Tokens include org_id and org_name. The architecture scenario says Organizations require Universal Login, and one tenant holds one user context. A separate context per organization is another tenant, which also changes SSO and where profiles live.

SAML is that same row. The IdP-initiated page recommends against a flow that starts at the identity provider, because Auth0 and the app both accept a response the user did not start, which is a login CSRF risk. The service-provider flow can put the organization id on the request. The connection has to be enabled for that organization, and the user has to be a member, unless the connection auto-joins them.

Those pages never name the database behind Auth0’s session cookie, so that store is a guess. The card leaves social login and SAML off this row.

Your browser talks to one Astro app. Node.js plus Astro is the default. Use TanStack Start if React is your weekday language. The capability line on the card is Astro, HTMX, and D1. Users, hashes, and sessions live in D1. The magic-link mail is the transactional email on the card. A plain form is enough for sign-in. The hash check stays on the server.

Screens of an Auth0 alternative

v1 needs the sign-in screen, the link confirmation, and the signed-in page. An admin list with revoke is the 4-day row.

Sign in

Ada sees an email field, a password field, and a way to ask for a link instead.

The link Ben receives

The screen after he asks for a link tells him to check the mail. The database holds the hash and the expiry.

Signed in

Ada’s projects page shows her email, the idle limit, and sign out.

How a sign-in becomes a session row

Ada’s form posts the email and password. The server checks the hash, inserts a session, and sets a cookie that holds the session id. Ben’s first request stores a token hash and sends the mail. Opening the link spends that hash and inserts his session. Sign-out deletes the row. Password reset and an admin revoke are the 4-day row. A Google button and an organization switcher are the long row.

The hard half of an Auth0 alternative

Twelve hours is a user, a hash, and a session row the cookie points at. Ada signs out and the next page asks her to sign in. Ben’s link works once.

The hard half is the other two sessions. An organization id changes which connections appear, and the token comes back with org_id. One tenant keeps one user context, so a separate context per customer is another tenant. Lumen’s two users fit in D1. The store behind Auth0’s session cookie is still unnamed on the pages above.

Paste the hash rule from How to write a coding agent prompt, and keep the split in How to scope a SaaS clone.

Start with the first row

Go to Build your own Auth0. Copy the Astro prompt, or TanStack Start if that is what you write.

Tell the agent the first estimate only. Users, a password or a magic link, and a session. Twelve hours.

Sign Ada in, open a second page, sign her out, and confirm the next request asks again. Open Ben’s link twice and confirm the second open does nothing. If you need SAML, a social button, or an organization, keep the plan you already pay for that part.