Stytch

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me authentication that replaces Stytch — and read the warning first, because this is the one category where building it yourself deserves the most caution.

**Fraud signals across many customers** are what the price buys: a provider sees the same attacker hitting a thousand applications and you see them hitting one. You cannot reproduce that. What you can build is authentication that is correct, and correctness is most of the value — but a mistake here is somebody else's account, so use reviewed libraries for everything cryptographic and do not invent anything.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- argon2 for passwords, a reviewed library for WebAuthn, and the platform's own randomness. Never a hand-rolled scheme
- Caddy in front

THE DATA MODEL
- users: id, email, email_verified_at, phone, phone_verified_at, password_hash, status, created_at, last_login_at, locked_until
- sessions: id, user_id, token_hash, ip_hash, user_agent_bucket, created_at, last_used_at, expires_at, revoked_at, revoke_reason
- credentials: id, user_id, kind, public_key, credential_id, sign_count, aaguid, label, created_at, last_used_at — passkeys
- factors: id, user_id, kind, secret_encrypted, confirmed_at — TOTP, and recovery codes stored hashed
- magic_tokens: id, user_id, token_hash, kind, expires_at, used_at, ip_hash
- oauth_identities: id, user_id, provider, subject, linked_at
- auth_events: id, user_id, kind, outcome, ip_hash, user_agent_bucket, at — append-only, and the basis of every defence below
- organisations and memberships, if you need business accounts

THE RULES THAT ARE NOT NEGOTIABLE
- Passwords with argon2id at parameters measured on your own hardware, and nothing else. Check every new password against a list of known breached ones — that single check does more than any complexity rule
- Session tokens are long random strings stored hashed. The cookie is httpOnly, secure, sameSite lax, short-lived, with a rotating refresh, and every session revocable centrally
- Every single-use token — reset, magic link, verification — expires, is invalidated on use, and is compared in constant time
- **Never reveal whether an address exists.** The same response and the same timing for a wrong password and an unknown account, on every route, including registration and reset
- Rate limits on every authentication route, per address hash and per account, with a lockout that fails closed and a documented unlock path
- A password change or a reset revokes every other session, and the user is emailed about it

PASSKEYS FIRST
- WebAuthn as the primary method, with a password as the fallback rather than the default. It is phishing-resistant, there is nothing to steal from your database, and support is now broad
- Several credentials per user, labelled, with the sign count checked and a decrease treated as suspicious
- Recovery matters more than registration: if somebody loses their only device they must have a way back, and that way back is the weakest link in the whole design. Make it deliberate — a second credential, or recovery codes issued at registration and stored hashed

THE FRAUD LAYER YOU CAN ACTUALLY BUILD
- Impossible travel: two successful logins from distant countries within an implausible window, computed from a local geolocation database. Flag, do not block
- Velocity: many failures across many accounts from one address range, or many accounts created from one address
- A new device or a new country prompting a second factor rather than a block
- Everything scored, with the reasons recorded, and a step-up challenge rather than a refusal. A hard block on a false positive is a customer who cannot get in and a support ticket you cannot resolve
- Every decision in auth_events, so 'what happened to this account' is one query

MULTI-TENANCY, IF YOU NEED IT
- Organisations with domain-based joining, roles, and single sign-on through OIDC or SAML per organisation
- SAML is unpleasant and unavoidable for enterprise customers. Use a reviewed library, validate signatures properly, and pin the certificate

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT, ENCRYPTION_KEY, SMTP_URL, GEOIP_DB_PATH
- Migrations on boot, each once; nightly backup off the machine
- Dependencies patched promptly — write that as an operational requirement
- Health endpoint

WHAT MATTERS MOST
Constant-time responses, real rate limits, and passkeys. Try to break each one deliberately: enumerate an address, reuse a reset token, log in without a limit. Everything else here is ordinary work; this is the part where a mistake belongs to somebody else.