Auth0 on X

What people praise is speed and time saved: one says an AI coding tool had Auth0 set up in 20 minutes where doing it by hand would have taken days, and others credit the TanStack Start SDK with wiring protected routes and sessions so they do not have to roll it themselves. Instant sign-in emails, the startups programme and the agent-identity work — an agent acting for a user, with approvals — carry the rest of the goodwill.

The plain picks, the next group at 7 people, are short replies to public "which auth tool?" threads, many just naming it; one adds a condition, that Supabase backends need no second vendor and other backends should use Auth0.

The enterprise line is a ranking rather than a complaint: "Supabase for value, Auth0 for enterprise". On cost, people treat Auth0 bills as a recurring cost worth engineering around, and one sets its monthly bill at scale against a $19-a-month backend that also includes sign-in.

Some of the friction is about having to run it at all: one has spent days on deployments "sans avoir la vue sur auth0", one is using Auth0 only as a stepping stone to something better, and one treats standing up an MCP server plus Auth0 as the hard part of a migration.

Price comes up for 2 people, who call the bill steep once users grow and worth engineering around.

2 people hit edges in the login flows: the Pre User Registration Action runs for database and passwordless signups but not social logins, challengeWith() cannot be used with redirect Actions, and SAML defaults to SP-initiated only, which one says puts the work on the IdP side.

2 people report things visibly breaking — a Google OAuth login that no longer works, issues piling up — and having to do unenjoyable things to get around them.

One person warns that user_metadata is editable by users, so authorization data kept there lets them grant themselves access.

The do-it-yourself camp splits between people who want full control over the experience and one who jokes about "replacing auth0 with asking jev if the user is real". The serious version is a boundary: one tells Auth0 that SAML and multi-tenant RBAC are where building your own starts to cost real time.

Logto is named as the open-source, self-hostable substitute; one writes up moving to it from Auth0 at the staging stage.

Clerk and Supabase Auth are weighed by how much you want to own: Clerk or Auth0 if you want it "done and out of the way", Supabase if you are already on its stack, and one who would pick Auth0 only for enterprise B2B.

Smaller and further out: Keycloak as the way around commercial billing, OpenAuth for a self-hosted stack, Cognito as a comparable option, and one reading of Skapi's pricing against Auth0's bill.

Both posts put the same short list up for a vote — Clerk, Auth0, Supabase Auth, "any other options" — and let repliers choose, so the answers land in reception rather than here, where people name Auth0, rank it for enterprise, or send the asker to Clerk or Supabase.

For a reader, the interesting part is the shape of the question: Auth0 arrives as one item on a three-name shortlist, asked by people starting a product, not as a default anyone is already committed to. The replies to those two threads are where the trade-offs get argued.

No question here is about a specific Auth0 feature, a plan, or a migration.

The request is narrow and put as a condition rather than a complaint: the person is not against passkeys, but will not commit while using them depends on the password database.

Nothing else in the posts asks Auth0 for a feature, so this is the whole of what people want it to become. On the page as a whole it is a single voice, not a pattern — the tokens will show one person.