Your first morning at a new office runs on two checks. The front desk compares your face to an ID, finds your name on a list, and hands you a keycard. The card opens the lobby gate and the fourth floor where your team sits, and when you tap it on the server room door, the light stays red. Two systems made two different decisions about you. The desk established who you are, once. The reader on each door decides what you may do, every time you tap.
Software with accounts runs the same pair of checks.
The most useful thing to know about auth is that these two checks never collapse into one: proving who someone is and deciding what they are allowed to do are separate jobs.
When a coding agent asks how users should log in, it is asking about the front desk. The doors are a separate job, and products that forget them let real strangers read real data.
Auth is two checks, not one
Authentication asks who you are. It is the front desk, the sign-in flow that turns an anonymous visitor into a known user, shortened in engineering writing to authN.
Authorization asks what you may do. It is the door reader, the permission rule that runs when a known user tries to read a record, edit a document, or open an admin page. Shortened to authZ, it belongs on every request the backend handles, because every request is a tap on some door.
Confusing the two causes real incidents that follow one recurring pattern: a team ships a login screen and relaxes, but the backend never checks which signed-in user is asking, so any customer can read any other customer's records just by changing an ID in a URL. Security write-ups call this broken access control, and it sits near the top of the industry's list of common web application risks. This is not an exotic hack, it is simply a missing permission check on one of the doors.
Never build login yourself
Login looks like a beginner-sized feature, one form with two fields. Underneath sits a stack of problems the industry needed decades to get right: storing passwords so a stolen database does not expose them, reset emails that cannot be hijacked, lockouts that stop guessing bots without trapping real users, and sessions that end on time. Each one is already solved, so writing your own login means breaking each of them again, one at a time, and often you only find out which one you got wrong when a breach notification arrives.
Services such as Clerk, Auth0, and Supabase Auth hand you the whole flow instead: sign-in screens, sessions, reset emails, and the user list, all maintained by teams whose entire job is keeping that machinery safe. In practice you never store a password, you call the service to learn who is signed in, and your attention goes to the spec below instead of the plumbing.
The sign-in methods you will choose from
When the service asks which sign-in methods to turn on, this is the 2026 menu.
- Email links. The user types an email address and receives a message with a link that signs them in. No password ever exists. Products call these magic links.
- Sign in with Google or Apple. The user clicks one button, and an account they already trust vouches for them. When a tool mentions OAuth, it means this family of borrowed sign-ins.
- Passwords. They are still everywhere and still the weakest entry on the menu, because people reuse them and attackers count on it.
- Passkeys. They are new enough to deserve their own section below.
For a first build, an email link plus one of the big buttons covers nearly everyone, and the service makes adding another method a setting rather than a project.
Passkeys replace the password with your screen lock
A passkey is a secret your device creates and keeps for one site or app. Signing in means approving with whatever already opens your phone or laptop: a face scan, a fingerprint, or the device PIN. There is nothing to type, nothing to reuse across sites, nothing for a phishing page to capture, and no password table sitting on a server waiting to be stolen. The major platform accounts already support them, and auth services offer them as an option you switch on rather than something you implement.
Many first builds need no auth at all
Accounts are permanent work: once they exist you maintain the flow, help the user who is locked out, and hold personal data, which brings the duties covered in The legal basics every public build needs. An account system you never build cannot be breached, so leaving auth out when you do not need it is a real win, not a corner cut. A tool only you run needs no sign-in, and neither does a public site that shows everyone the same content. We shipped the site you are reading with no accounts at all, because nothing here is gated.
The test for your build: finish this sentence for each feature you were about to gate. "If any stranger on the internet could do this, the specific harm would be..." When you cannot name a real harm, skip auth for now, because adding a service later is days of work, not a rewrite. When the harm is obvious (private records exposed, money moving, content posted under someone's name), you need both checks from day one.
The three-line auth spec
When the build does earn auth, answer the agent's login question with three lines.
- Who signs up. Anyone with an email address, only people you invite, or only addresses at one company's domain.
- How they sign in. Pick from the menu above, such as an email link plus Google, with passkeys on where offered.
- What each kind of user may do. Name the roles and draw the lines between them.
For a small consultancy's client portal, the spec might read: anyone with a company email address can sign up; they sign in with Google; consultants see their own clients' notes while partners see every client plus invoicing. The third line is the authorization half, the one beginners drop, and writing it forces decisions a login screen would have hidden. Hand these lines to your agent and the service choice and wiring become its job, and the spec drops straight into the plan you will assemble in Write your Build Plan and start the build.
Try it now
No setup: Run a sign-in audit on two or three AI products you already use, such as a chat assistant, an email drafter, and a meeting notetaker. For each one, open the sign-in screen and list the methods on offer: password, email link, Google or Apple, passkey. Then sign out and record what changes: what you can still read, what locks, what disappears. You are reading each product's auth spec from the outside, since the methods are its second line and the signed-out experience traces its third.
With your tools: Write the three-line auth spec for the idea you have carried through this level. Open Claude Code, paste the spec, and ask which auth service it would wire in and why, then what it would check on each request to enforce your third line. Push back once and ask what gets simpler if you drop a requirement. In Codex or Cursor the move is the same: give the sidebar chat your spec and ask for the service pick and the per-request check. If your tools are not set up yet, The Setup Clinic gets you there in one sitting.
Chapter Summary
- Auth is two separate checks: authentication proves who a user is, and authorization decides what that user may do.
- A product is only safe when both checks run, and the permission check has to run on every meaningful request, not just at sign-in.
- A login screen on its own is not security. The classic incident is a backend that never checks which signed-in user is asking, so anyone can read anyone else's records.
- Do not build login yourself. Rent it from a service like Clerk, Auth0, or Supabase Auth, so you never store a password and never rebuild machinery the industry took decades to get right.
- The 2026 sign-in menu runs from email links, through Google and Apple buttons, to passkeys, and you can add another method later as a setting.
- Passkeys swap the password for whatever already opens your phone or laptop, so there is nothing to type, reuse, or phish.
- Many first builds are better off with no accounts at all. If you cannot name a real harm from letting a stranger do something, skip auth for now.
- When a build does need auth, three lines cover the whole conversation: who signs up, how they sign in, and what each kind of user may do.
- Everything you have built so far can fail quietly, sign-in included, and Monitoring, how you know it broke (and what it costs) is how you find out before your users do.
Sources
- OWASP Top 10, on broken access control as a leading web application risk.
- FIDO Alliance documentation on passkeys.