L22 · Build & preview · 5 min
Logins and accounts
In one sentence
Accounts and logins let your app recognize returning visitors and protect their private data, using Better Auth, a database, and an unseen secret key—and you only add them when your app genuinely needs to remember who someone is between visits.
Think of it like this
A public park doesn't ask for ID at the gate, because anyone can walk in. A gym does, because it keeps your locker and membership tied to you—and instead of you building the turnstile from scratch, you install a tested lock system.
How it works
Each app gets only what it needs: if your app is a calculator, a directory or a personal site where nothing belongs to a specific person, skip accounts altogether. Once your Definitionspec`SPEC.md`: what you're building, who it's for, what's in and out, and how you'll know it works.Open in the glossary → calls for personal data that must stay private across visits, you need both a DefinitiondatabaseWhere your app remembers things between visits, like accounts or saved recipes.Open in the glossary → (Neon) and an authentication library (Better Auth).
When someone signs in, Better Auth creates a session—a signed pass stored in an HTTP-only browser cookie that says “this browser is signed in as user X” until it expires or they sign out. To sign those passes safely, your app uses two Definitionenvironment variableA named slot, like `TOKENTIDE_API_KEY`, that holds a setting or secret outside your code.Open in the glossary → settings: BETTER_AUTH_URL (your site's address, or http://localhost:3000 on your computer) and BETTER_AUTH_SECRET (a random DefinitionsecretAnything that opens your accounts: API keys, passwords, tokens. Kept only in Vercel and `.env.local`.Open in the glossary → your agent generates and sends straight to .env.local and DefinitionVercelThe service that turns your code on GitHub into a live site, with a Preview for every change.Open in the glossary → without ever printing it in the chat).
Never let an agent invent its own password handling. Using Better Auth with its security DefinitionskillAn expert playbook your agent follows for a kind of task, like writing a spec or debugging.Open in the glossary → gives you salted password hashing, protection against forged requests (CSRF), trusted origins for DefinitionPreviewA private test link Vercel makes for each change, so you can try it before it goes live.Open in the glossary → links, and database-stored Definitionrate limitA cap on how often something can be done, like sign-in attempts per minute, to stop abuse.Open in the glossary → rules so an attacker cannot guess thousands of passwords per minute.
Signing in on the DefinitionfrontendThe part of an app that runs in the visitor's browser: what people see and click.Open in the glossary → is only half the job. Every DefinitionbackendThe part of an app that runs on a server: it keeps data, checks logins and talks to other services.Open in the glossary → action that reads or changes private data must check the session on the server first, and verify that the signed-in person is allowed to touch that record.
What it looks like in your project
When your plan reaches logins, your agent loads the better-auth-best-practices and better-auth-security-best-practices skills, generates a fresh unseen BETTER_AUTH_SECRET for .env.local and another for Vercel, creates the auth tables in your Neon development branch, and builds the sign-up, sign-in and sign-out screens.
Copy for your agent
Check whether my app's SPEC.md actually needs user accounts. If it does, explain how we'll set up Better Auth with database-stored rate limits and unseen secrets before writing any code.
Quick check · 1 question