| name | auth-basics |
| category | code |
| description | Add real sign-in to their app. Uses provider-managed identity, working sessions, server-side authorization, test accounts, and secret handling. Never roll your own password storage. Use when an app needs accounts, when data should be private per user, or when they ask "how do logins work". |
auth-basics
Add real authentication to someone's app: users can sign
in, stay signed in, sign out, and see only their own data. The one
rule that must survive this session forever: they never build their
own password storage. Identity comes from a provider that does it for
a living.
Ground rules
- Auth must protect something real. If the app has no per-user data
yet, define it first (their tracker entries, their saved items).
Auth on an app where everyone sees everything teaches nothing.
- Use OAuth with a provider they already have or a managed identity service.
Compare current official documentation, plan limits, recovery controls, and
data-handling terms before choosing. If email
and password is truly needed, the managed provider stores the
passwords; their code never touches one.
- Their accounts everywhere. They create the OAuth app in their own
GitHub settings and paste the client secret into env vars
themselves. Client secrets are secrets: host env vars plus
gitignored
.env, never in frontend code, never committed. Check
with git status before the first commit that touches auth.
- Say the vocabulary plainly as it appears: authentication is who you
are, authorization is what you may do, a session is how the server
remembers you between requests. Three sentences each, in context,
when the code makes them concrete.
- Never trust the client. Every who-sees-what check runs server-side
(or in database row-level security). Hiding a button is not
security, and you demonstrate that with dev tools.
The path
- Decide what is private: which data belongs to a user, what a
signed-out visitor sees. Write it down as two or three rules.
- Register the OAuth app or auth project in their account. Callback
URL, client ID, client secret into env vars.
- Sign-in works: the login button, the redirect dance, and back with
a session. Inspect the returned user fields locally without copying
tokens or personal data into logs; remove temporary debug output before
deployment.
- Sessions hold: refresh the page, still signed in; sign out, signed
out everywhere. Explain the cookie doing the remembering.
- Enforce the rules from step 1 on the server or with row-level
security: user id attached to their rows, queries filtered by it,
a request for someone else's data refused with a 401 or 403.
- Test authorization with two accounts created for this purpose and test
records only: call the API signed out, edit the user id in dev tools, and
try to read the other test account's row. Every attempt must fail. Never
probe another real user's account or data.
Done
- Sign in with a real provider works live; sessions survive refresh;
sign-out works
- Per-user data enforced server-side, verified by trying to break it
- No password ever stored or handled by their code
- Secrets in env vars only, absent from the repo
- They can explain authentication, authorization, and sessions in
their own words
Then: this unlocks any multi-user idea in the bank; database-basics
pairs with it if rows are not yet owned by users.
