Auth, who you are vs. what you can do

AI asks: How will users log in?

Auth is one of the two areas of software engineering where building it yourself, badly, is the most common path to a career-defining security incident. (The other is taking credit cards, where the answer is similarly: use Stripe, do not roll your own.) Today's lesson teaches the mental model so you can confidently say "let's use a service for this" when AI asks.

The two halves of "auth"

You will see two words used near each other constantly, and they mean different things.

Authentication (authN). "Who are you?" The login flow. The thing where a user enters an email and password (or signs in with Google, or uses a magic link) and your system goes "OK, this is Girish."

Authorization (authZ). "What are you allowed to do?" The permission rules. The thing that decides whether Girish can edit a particular document, whether he can see other users' messages, whether he has admin access.

Confusing the two is the source of approximately 90% of beginner security incidents. The classic version goes "I added login to my app, I'm safe now," but adding login only solves authN. If your backend does not separately check, on every request, that the user is allowed to do the specific thing they are asking to do, your users can read each other's data, edit each other's records, and (in the worst cases) do whatever an admin can do.

Authentication says who you are. Authorization decides what you can do. Both are required.

What "use a service" looks like

Modern auth services give you both halves, in a few hours of setup, in a way that is more secure than what you would build yourself.

The shape: you sign up for an auth provider, you drop their SDK into your app, you call a couple of functions ("sign in," "sign out," "is this user allowed to do this thing"), they handle the rest. Email and password, social logins (Google, Apple, GitHub), magic links, two-factor authentication, session management, password resets, all of it.

Good options in 2026:

• Clerk. The most opinionated, the most polished, the most fun to set up. Strong default.
• Auth0 (Okta). The enterprise standard. Slightly heavier, very capable.
• Supabase Auth. If you are already using Supabase for your database, the auth comes with it, and it is good.
• NextAuth / Auth.js. Open-source, lives inside your codebase, lots of flexibility, more setup to think about.
• Stack Auth, Kinde, WorkOS. Newer options, worth a look if Clerk doesn't fit your case.

For most builds, the right move is: pick Clerk or Supabase Auth, set it up in an afternoon, do not write your own login form.

How to answer "how will users log in"

The format that works is to specify three things.

Who can sign up. Anyone with an email? Only people you have invited? Only people in a specific company's domain?

What sign-in methods. Email and password, social login (Google, Apple, GitHub), magic links, or all of the above?

What happens after. What is the first thing the user sees once they are in?

That is enough specification for any AI tool to wire up a working auth flow with a service. Day 18 will return to this when we sketch your specific build's stack.

A small vocabulary sweep

• Session. A logged-in browser tab. The mechanism that remembers you are signed in between requests.
• Token. A small piece of cryptographic proof that a user is who they say they are. Sessions are usually backed by tokens.
• OAuth. The protocol that powers "sign in with Google" and similar. You do not need to understand it. You need to know that when AI mentions OAuth, it is talking about social logins.
• 2FA / MFA. Two-factor or multi-factor authentication. The "enter the code from your authenticator app" step. Modern auth services give it to you free.
• Role-based access control (RBAC). A common pattern for authorization, where users have roles ("admin," "member," "guest") and each role has a set of permissions.

Forward references

Day 14 covers monitoring, which is how you find out when something has gone wrong with the systems we have spent two weeks naming. Day 19 returns to authN and authZ in the guardrail checklist for builders. Day 20 covers the legal obligations that kick in the moment you start collecting personal information through your login flow.

Day 13 wrap

The thing you can now say plainly. Authentication is who you are (the login). Authorization is what you can do (the permissions). They are two different jobs, and confusing them is the most common cause of beginner security incidents.

The thing you can now do. When AI asks "how will users log in," specify who can sign up, what methods, and what happens after. Then pick an auth service and stop trying to build login yourself.

The guardrail to remember. AuthN without authZ is a door without a hallway. Both have to be there before you ship.

See you on Day 14, where we figure out how you would even know if something broke.