Auth

Auth is the bouncer.

A website without auth is a shop with the door off. Anyone can walk in and rearrange the shelves. That's fine for a landing page. It's a disaster for "my todos."

Auth is short for authentication (who are you?) plus, usually, authorization (what are you allowed to touch?). People mash those together. You can keep them separate in your head: first the ID check, then the velvet rope.

What actually happens

1. Someone proves they're them — password, Google button, magic link.
2. You give them a badge (a session cookie or a token).
3. Every later request shows the badge at the API window.
4. The backend looks at the badge and decides if "delete this todo" is their todo.

If you skip step 4, you built a costume party. Anyone with a URL can wear someone else's name.

Better Auth vs Clerk

• Better Auth — the bouncer lives in your house. You own the users table. More setup, no vendor at the door.
• Clerk — you rented a professional bouncer. Sign-in UI, user list, the "forgot password" emails. Faster to a demo. Their building, their rules.

none is honest when you don't have users yet. Add it before you store anything you'd be sad to lose.

Don't invent this at 4 a.m.

Password hashing, session theft, "oops I logged in as the other judge" — this is solved, boring, and easy to get wrong. Use a library. Let the library be boring.

What this unlocks

Once there's a bouncer, the rest of the app can ask a simple question: "whose stuff is this?" That's how a demo turns into something you could actually ship on Monday.