auth-basics

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

1. Decide what is private: which data belongs to a user, what a signed-out visitor sees. Write it down as two or three rules.
2. Register the OAuth app or auth project in their account. Callback URL, client ID, client secret into env vars.
3. 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.
4. Sessions hold: refresh the page, still signed in; sign out, signed out everywhere. Explain the cookie doing the remembering.
5. 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.
6. 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.