There is no password in this kit. There never will be. Email-and-password is never enabled, and that is a security stance rather than a missing feature.
If your requirements name password sign-in, this capability says no rather than not yet.
What you get instead
Auth is the capability that decided this, the token model is what a signed-in reader actually holds, and signing in on the web is the shortest version of the flow.
Magic link. Email one-time code. Google, Apple, GitHub, Facebook.
Every one of them proves the same thing a password is supposed to prove — that this is the person who controls this address or this account — without any of them requiring you to store a secret on their behalf.
What you do not have to build
The list is longer than people expect, and every item on it is a place things go wrong:
- A password hashing choice, and an argument about its cost factor
- A password strength policy, and the reset flow when somebody fails it
- A forgot-password email — which is a magic link with extra steps
- A password change flow, and the sessions it should invalidate
- A breach-list check
- A rotation policy nobody follows
- Rate limiting on a credential-stuffing surface that exists only because you have credentials to stuff
That sixth-to-last one is the argument in miniature. A password reset email is a magic link. If you build passwords, you build magic links too — and then you maintain both, and the weaker one is your real security posture.
What to tell a security reviewer
Four sentences, in the order they will ask.
There is no password database. Nothing to leak, and a breach of the users table yields addresses rather than credentials.
There is no password to phish, because there is nothing a user could be tricked into typing on a fake page that would work on the real one. A magic link is single-use and bound to the address it went to.
Credential stuffing has no surface. Reused passwords from another site’s breach are not applicable, because there is no password field to try them in.
Rate limiting is two tiers, not one. Cloudflare’s native limiter caps requests per client IP at the edge in front of every auth route, with no storage round-trip. A second, database-backed limiter caps per action and identity — because in-memory limiting is per-isolate on Workers and therefore useless.
The objections that are actually fair
Email becomes the single point of failure. Somebody who controls the mailbox controls the account. That is true — and it is also true of any system with a password reset flow, which is nearly all of them. The difference is that here it is visible rather than pretended away.
Mitigate it the way you would anyway: encourage a provider with strong account security, and offer a second factor through a plugin if your risk warrants one.
Deliverability is now on the critical path. If mail does not arrive, nobody signs in. That is real, and it is why mail is a durable job with retries rather than an inline send, why bounces feed a suppression list, and why Deliverability is a page rather than a footnote.
The one-time code helps here: it is the same proof without a link to click, and it survives a mail client that rewrites URLs.
Some users find it unfamiliar. Fewer every year, and a one-time code reads as familiar to anybody who has used a bank app.
An enterprise checklist may name password policy. If it names it as a control rather than an outcome, this will be a conversation. The outcome — credentials cannot be reused, leaked or guessed — is met more strongly by not having them.
No impersonation, either
Related, and worth naming in the same breath because reviewers ask about both.
There is no sign in as this user. It mints a credential indistinguishable from the person’s own, so every action taken with it reads in the audit trail as theirs.
It is excluded on purpose and it is not reachable by composing what is here: no route mints a session, and no read projects a session token. If it is ever built it gets its own design and its own security review.
The management surface does the legitimate half of what people want impersonation for — look somebody up, see their devices, revoke a session — behind five separate scopes, so a support tool that finds people cannot also sign the customer base out.
Composing more
Better Auth’s ecosystem is open, and a second factor, passkeys or an API-key scheme all compose through the capability’s own config.
Four plugins are fixed — bearer, JWT, magic link and one-time code — and they compose first. They are fixed because the rest of the kit depends on them: magic link and one-time code are the sign-in this product promises, and there is no password to fall back on.
Passkeys are the interesting one to add. They are the thing that actually improves on this, rather than reverting from it.