Skills / Auth basics

Auth basics

Q: Will my code ever store a password?

No. OAuth means the provider does identity; managed auth means the provider stores any passwords. Your code handles sessions and permissions only.

Q: What if my users don't have GitHub?

Use a managed auth service's free tier for email and password sign-in, where the service does the storing. Free-tier limits are named honestly first.

Q: Isn't hiding the button enough?

No. Dev tools can un-hide anything the browser hides. Checks run on the server or in row-level security, where the client can't reach them.

Q: Does auth cost anything?

GitHub OAuth is free, and managed providers have free tiers that cover a personal app, with limits stated before you sign up.

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".

Use this skill. Nothing to install.

Open in ChatGPT Open in Claude prefilled and ready; just hit send

for Gemini, Copilot, or Cursor: paste it, then say "use the auth basics skill"

Don't have an agent? · Raw file: skills/auth-basics.md

Watch the first two minutes

This is how a session goes, including the part everyone is afraid of. Click through it.

(pastes the skill) i want people to log into my study tracker so everyone has their own entries

Good reason for auth: there's real per-user data to protect. First question: do you have a GitHub account?

yeah. but storing people's passwords honestly freaks me out

It should, and you never will. That's the one rule from this session that lasts forever: identity comes from a provider that does it for a living. With GitHub OAuth, no password ever touches your code.

then how does my app know who someone is?

The login button sends them to GitHub, GitHub asks them, and they come back with a session: a cookie your server uses to remember them between requests. We'll log the user object once so you see exactly what the provider returns.

and how do i stop one user from reading another's entries?

Every check runs server-side. Each row gets a user id, each query filters by it, and a request for someone else's data gets a 401 or 403. At the end we attack it together with curl and dev tools, and every attempt has to fail before we're done.

Scripted example of a real session.

I don't want to be responsible for people's passwords

You won't be, and the skill enforces it: you never build your own password storage. Sign-in goes through OAuth with a provider your users already have (GitHub is ideal for this audience) or a managed auth free tier. If email and password is truly needed, the managed provider stores the passwords and your code never touches one. What you are responsible for is the part you can actually verify: per-user rules enforced on the server and tested by trying to break them. These projects all needed exactly that:

Club HQ with member accounts

Tool lending library

Order desk

What you end up with

Sign-in that works live, sessions that survive a refresh, and rules you verified by attacking them. The last step of the skill produces a log like this one.

Example

ATTEMPT 1: READ ENTRIES WHILE SIGNED OUT

$ curl https://tracker.example.com/api/entries
HTTP 401 {"error":"sign in required"}

ATTEMPT 2: SIGNED IN, READ YOUR OWN ENTRIES

$ curl -b session.txt https://tracker.example.com/api/entries
HTTP 200 [{"id":311,"subject":"calc","minutes":45}, ...]

ATTEMPT 3: SIGNED IN, READ SOMEONE ELSE'S ROW

$ curl -b session.txt https://tracker.example.com/api/entries/298
HTTP 403 {"error":"forbidden"}

The 401 and the 403 are the deliverable. Sign-in working is the easy half; requests for other people's data being refused is what makes the app trustworthy.
You ran these attacks yourself. curl while signed out, ids edited in dev tools, another account's row requested directly. The step isn't done until every attempt fails.
Row 298 exists and belongs to someone else. Ownership lives in the database (a user id on every row) and in every query, where the browser can't change it.

Questions people actually ask

Will my code ever store a password?

No, and that's the rule the whole skill is built around. OAuth means the provider does identity; managed auth means the provider stores any passwords. Your code handles sessions and permissions, never a password.

What if my users don't have GitHub?

Then you use a managed auth service's free tier, which gives you email and password sign-in where the service does the storing. The skill names the free tier's limits honestly before you pick one.

What's the difference between authentication and authorization?

Authentication is who you are; authorization is what you may do. A session is how the server remembers you between requests. The skill introduces each word at the moment the code makes it concrete, so they stick.

Isn't hiding the button enough?

No. Anything the browser hides, dev tools can un-hide, and the skill demonstrates that on your own app. Every who-sees-what check runs on the server or in the database's row-level security, where the client can't reach it.

Does auth cost anything?

GitHub OAuth is free, and managed auth providers have free tiers that cover a personal app. As always in this catalog, the limits get said out loud before you sign up, and no card details go anywhere.

Where to go from here

Accounts unlock every multi-user idea in the bank:

Alumni directory

Club election

School swap marketplace

Shore up the layers auth sits on:

Database basics: rows to own

Backend basics: the server side

Build a web app: the frontend

Ideas to use it on

An alumni and mentors directory that opts in — A directory connecting students at your school with alumni and adult mentors who explicitly opted in: where they work or study, what they'll take questions about, and how they prefer to be reached.
A membership and dues tracker for a real club — A membership roster and dues ledger for a club you actually belong to.
A club election people can trust — An election system for a real vote your club actually needs to hold: officers, a budget priority, next semester's event.
The platform your club actually runs on — A management platform for a club you are actually in: member roster, events with RSVP, attendance taken at real meetings, and announcements from officers.
An order desk for a real business — An order-request system for a real small business: a family bakery, a neighbor's tailoring shop, a friend's sticker shop.
A buy-and-sell board for your school — A listings board for students at your school: textbooks, calculators, uniforms, concert tickets someone can't use.
A study-group scheduler with real sign-in — A scheduler for a study group that currently plans everything in a chat thread.
A stats platform your whole team updates — A stats site for a team you play on or manage, where the team itself enters the data.
A lending library for neighborhood tools — A lending system for physical things your street or building already shares informally: ladders, drills, camping gear, a sewing machine, board games.
Volunteer hours a real org can verify — An hours platform for an organization you already volunteer with: an NHS chapter, a food bank, a library program, a religious youth group.

Curious? Read the full skill — the exact instructions your agent gets

---
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.