Authentication and User Identity
Learn to add real auth to a SaaS backend — password hashing, session cookies, OAuth2 sign-in with GitHub/Google, email verification + password reset, MFA with TOTP and a passkeys preview, and role-based access control. Library-track for Phase 1; cloud variants (Firebase Auth, Microsoft Entra External ID) in a later release.
About This Course
Add real authentication to a SaaS backend the kind that lets customers sign up, sign in, verify their email, protect their account with a second factor, and only touch the data they're allowed to touch. By the end of this course you will know how password hashing actually works (and why MD5 isn't it), how session cookies carry identity between requests, how OAuth2 lets users sign in with their existing GitHub or Google account, how email verification and password reset flows are built on single-use tokens, how TOTP (the Authenticator-app code) and passkeys protect against stolen passwords, and how role-based access control decides who can call which endpoint. Every lesson pairs a short teaching segment with a hands-on lab in which Claude Code writes the auth plumbing for you you learn what to ask for and why each piece is in the design.
Course Curriculum
10 Lessons
Password hashing and session cookies — how a login actually works
Learn what happens between a user typing a password and a server deciding to let them in. You will understand why servers never store passwords in plain text (and why hashing with MD5 or SHA-1 isn't enough either), what Argon2id is and why it's the modern default, and how a session cookie carries a user's identity from one request to the next without the user re-typing their password every time.
Build sign-up, sign-in, sign-out, and /me - Lab Exercises
Build the four endpoints every SaaS auth system has: POST /signup (hash the password, create the user), POST /signin (verify the password, start a session), POST /signout (end the session), and GET /me (return the current user's info — protected by the session). You will direct Claude Code to add Argon2id hashing, a Postgres-backed sessions table, and the cookie plumbing that ties them together.
OAuth2 — "Sign in with Google" explained in plain English
Learn what happens when a user clicks "Sign in with GitHub" and ends up logged in to your app without ever typing a password on your site. You will understand the three parties in every OAuth2 flow (your app, the identity provider, the user), the authorization-code dance that gets your server a short-lived token, and why OAuth2 is only half of a sign-in system — you still have to decide what to do with the returned identity.
Add "Sign in with GitHub" to Lumen Trail - Lab Exercises
Direct Claude Code to add a complete OAuth2 flow to the Lumen Trail auth: a GET /oauth/github/start endpoint that redirects the user to GitHub, a GET /oauth/github/callback endpoint that exchanges the code for a token and either links the GitHub account to an existing user or creates a new one. You will create your own GitHub OAuth app, configure the client id and secret, and complete a real end-to-end login.
Email verification and password reset — the single-use-token pattern
Learn the shared pattern behind "click this link to verify your email" and "click this link to reset your password" — both are built on single-use tokens that are long, random, time-bounded, and matched against a server-stored record. You will see what the token actually looks like, why it has to be single-use, and the small set of mistakes that make these flows insecure in production.
Add email verification and password reset with Resend + MailHog - Lab Exercises
Direct Claude Code to wire email verification into sign-up (new accounts get a email_verified flag and a verification link mailed to them) and a password reset flow (user enters email, receives a reset link, lands on a form that updates the password). You will use MailHog — a local SMTP catcher built into the lab container — so no real email account is needed; the Resend SDK talks to MailHog's web UI where you can see every email your server sent.
Multi-factor auth — TOTP today, passkeys tomorrow
Learn why a password alone isn't enough to protect a modern account and the two families of second factor: TOTP (the Authenticator-app six-digit code — RFC 6238, straightforward to implement, universally compatible) and passkeys (WebAuthn — the phishing-resistant passwordless successor, broadly supported in 2026 and the direction the industry is moving). You will build TOTP in the hands-on and get a concept-level tour of passkeys as the upgrade.
Add TOTP second-factor auth to Lumen Trail - Lab Exercises
Direct Claude Code to add a TOTP enrollment flow (generate a secret, show the user a QR code, verify a first code to confirm their Authenticator app is set up), a signin-with-TOTP flow (after password check, require the current six-digit code), and backup codes stored hashed in the database. You will scan the QR code with your phone's Authenticator app and complete a real end-to-end second-factor login.
Authorization — who can call which endpoint, and who can touch which row
Learn the difference between authentication ("who are you?") and authorization ("what are you allowed to do?"), the two levels of authorization every SaaS app has (route-level — can this user call this endpoint? — and row-level — can this user touch this specific row?), and the standard pattern that handles both: role-based access control (RBAC) plus explicit ownership checks on each resource.
Protect Lumen Trail endpoints with roles and ownership checks - Lab Exercises
Direct Claude Code to add a role column to the users table (user / admin), a requireRole middleware that enforces route-level authorization, and ownership checks that make sure users can only delete their own items. You will try to break each check from a test account and watch the server refuse — the correct, boring behavior that keeps a shipping SaaS safe.