Phase 7Days 80-92

Authentication Deep Dive

Cryptography, sessions, JWT, magic links, OAuth, NextAuth — the right tool every time

Phase Goal

Understand cryptography from first principles — hashing, symmetric and public-key encryption, signatures, TLS, and end-to-end encryption — then implement password auth properly, understand JWT vs sessions, ship passwordless/magic-link login, wire OAuth (Google + GitHub), and deploy NextAuth with RBAC and audit — knowing which to use when.

Progress

Notes

Open the written lectures for this course before checking off the phase topics.

Mini Projects

Chain-of-Custody Crypto Lab

Sealed Whistleblower Drop

Projects

Member Access Gateway (rehearsal)

Consent-Based Records Release Console — DEPLOYED

Day 80: Cryptography from Scratch — Encoding, Hashing & Encryption

A bit is a single binary digit, 0 or 1. A byte is 8 bits, so one byte can hold 2^8 = 256 different values — that is where the number 256 first shows up, and it is not the 256 in SHA-256When something is called "256-bit", it means the value is 256 bits long, which is 32 bytes. That is the entire meaning of the 256 in SHA-256: the output is 256 bits long, every single timeWhy you always see them as hex: each hex character encodes 4 bits, so 2 hex characters per byte, so a 256-bit value prints as exactly 64 hex characters — that long string you have seen a thousand times and never countedBase64 is another way to print bytes as text (about 4 characters per 3 bytes). Hex and base64 are both just spellings — neither hides anythingThe sizes you will meet in this phase: 256-bit hashes, 128- or 256-bit AES keys, 2048-bit RSA keys, 256-bit elliptic-curve keys. In every case the number answers one question: how many bits long?Why bigger means safer: each extra bit doubles the number of possibilities. 2^128 is already more than every computer that will ever exist could enumerate, which is why key sizes stop growing at some point rather than climbing foreverDo it now: print the same string in Node as raw bytes, as hex, and as base64, and confirm that all three round-trip perfectly with nothing secret involved

Encoding (base64, hex, URL-encoding) changes how bytes are written down so they survive a text channel. Anyone can reverse it, instantly, with no secret. It is not security in any formHashing is one-way: any input of any size goes in, a fixed-size fingerprint comes out, and there is no route back. There is no key involved at allEncryption is two-way and needs a key: the data is scrambled, and only someone with the right key can unscramble itThe two classic wrong answers, and why each is wrong: "we base64 the password" is not protection because anyone can decode it; "we encrypt passwords in the database" is wrong because encryption is reversible, and you should never be able to recover a user's passwordChoose by asking one question — do I ever need the original value back? Never → hash it. Yes, and only I should read it → encrypt it. I just need it to survive JSON or a URL → encode itWhere each already lives in your app: base64 in the three parts of a JWT and in data URLs, hashing for password storage and integrity checks, encryption for HTTPS and for secrets at restSay this cleanly in an interview and you have already outperformed most candidates, because these three words get used interchangeably by people who should know better

Definition first: a function that takes an input of any length and returns an output of fixed length, and returns the same output for the same input every time, forever, on every machineFour properties make a hash cryptographic — deterministic, fast to compute, one-way (given the output you cannot find the input), and collision resistant (you cannot find two inputs with the same output)The avalanche effect: change a single character of the input and roughly half the output bits flip. Hash "hello" and "hellp" and compare — the outputs share nothing, which is why a hash reveals nothing about its inputCollisions must exist, mathematically: infinite possible inputs, finite possible outputs. The security promise is not that collisions do not exist, it is that nobody can find oneThe birthday paradox, applied: because you only need any two inputs to collide rather than a specific one, a 256-bit hash gives about 128 bits of collision resistance — roughly 2^128 attempts, not 2^256. This is exactly why 256-bit outputs are the modern defaultWhat a hash is not: not encryption (no key, no reverse), not compression (the data is gone, not squeezed), and not a random number (it is fully deterministic)The one-line version to remember: a hash is a fingerprint — it identifies data without containing it

SHA stands for Secure Hash Algorithm, a family published by NIST (the US standards body). The number after the name is simply the output length in bits, so SHA-256 produces 256 bitsThe family tree, because interviewers ask: SHA-0 was withdrawn almost immediately; SHA-1 produces 160 bits and is broken (a real collision was demonstrated in 2017, so it must not be used for security); SHA-2 is the current workhorse and includes SHA-224, SHA-256, SHA-384 and SHA-512; SHA-3 has a completely different internal design and exists as insurance in case SHA-2 ever fallsSo "SHA-256" means: the SHA-2 algorithm, configured to output 256 bits = 32 bytes = 64 hex charactersInside, at the level you need: the message is padded to a multiple of 512 bits (including the original length, which matters), split into 512-bit blocks, and each block is mixed into a 256-bit internal state through 64 rounds of rotations, XORs, and additions. Each block's result feeds into the next — a construction called Merkle-DamgårdWhere the strange constants come from: the fractional parts of square and cube roots of the first small primes. They are chosen this way so that no one can claim the designers hid a backdoor in them — the term is "nothing-up-my-sleeve numbers"The known weakness of this construction: length extension. Given hash(secret + message) and the length, an attacker can compute hash(secret + message + extra) without knowing the secret. This is precisely why you never authenticate by concatenating a secret and hashing — you use HMACRun it: crypto.createHash("sha256").update("hello").digest("hex") in Node, count the 64 characters, then change one letter and watch the entire output change

Integrity: file checksums, git commit and object ids, content-addressed storage. The same bytes always produce the same name, so the name proves the contentDeduplication and cache keys — a hash of the input is a compact, collision-safe identifier for anythingDigital signatures: you never sign a whole document, you sign its hash. That is why signatures are fast regardless of file size (and you will use this tomorrow)HMAC — a hash keyed with a secret, built specifically to prove both that the message is unchanged and that it came from someone holding the keyYou have already relied on HMAC twice: verifying Stripe and Razorpay webhook signatures, and the HS256 variant of JWT signingWhere a plain hash is deliberately the wrong tool: passwords. A fast hash is a liability there, because fast means an attacker can try billions per second. Password hashing is its own discipline with its own algorithms — that is the very next dayThe rule to carry out of today: SHA-256 of a password is a security bug, not a security measure

Symmetric means one shared secret key both encrypts and decrypts. AES (Advanced Encryption Standard) is the algorithm essentially everything uses; AES-256 means a 256-bit keyAES is a block cipher — it operates on fixed 16-byte blocks — so a "mode of operation" decides how a long message is split and chainedECB mode encrypts each block independently, so identical input blocks produce identical output blocks and the shape of your data shows straight through. The famous encrypted-penguin image is ECB. Never use itCBC mode chains each block into the next and needs a random IV (initialisation vector), so encrypting the same message twice gives different ciphertext. Better, but it proves nothing about tamperingGCM mode adds authentication: you get ciphertext plus an authentication tag that fails loudly if a single bit was altered. This is the category called AEAD, and it is what you should use by defaultThe nonce rule that has broken real production systems: never reuse an IV/nonce with the same key. Generate a fresh random one per message and store it next to the ciphertext — it is not secretA password is not a key. Turning a password into a key requires a deliberate key-derivation function (PBKDF2, scrypt, Argon2), which is slow on purpose

In Node: crypto.createCipheriv("aes-256-gcm", key, iv) gives you ciphertext, and getAuthTag() gives you the tagDecrypt it back, then flip one byte of the ciphertext and try again — the auth tag check throws. That failure is authentication doing its jobWhat travels together and what stays secret: ciphertext, IV, and tag all get stored or sent; only the key is protectedReal uses in a web app: encrypting third-party API tokens or personal data in a database column, encrypting cookie contents, encrypting a backup before it leaves your machineKey management is the genuinely hard part — an environment variable is the starting point, a managed KMS is the grown-up answer, and a key stored in the same database as the ciphertext protects nothing at allPlan for rotation before you need it: version your ciphertext so you can decrypt with the old key and re-encrypt with the new one

Mini Project

Chain-of-Custody Crypto Lab

Build a tiny CLI that demonstrates each primitive on the same input: hex/base64 encode and decode, SHA-256 with an avalanche demo on a one-character change, HMAC-SHA256 with a secret, and AES-256-GCM encrypt/decrypt including a deliberately corrupted ciphertext that fails the auth tag. Print what is secret and what is not at each step, and write a short README explaining which of the three (encode/hash/encrypt) you would use for five given scenarios.

Day 81: Public Keys, Signatures, TLS & End-to-End Encryption

Symmetric encryption has one fatal gap: both sides need the identical key, and getting that key to the other side safely is the original problem all over againAsymmetric (public-key) cryptography solves it with a pair of mathematically linked keys: a public key you can publish on a billboard, and a private key you never share with anyoneTwo different uses, and mixing them up is the most common confusion — encrypt with someone's public key so only their private key can read it, or sign with your private key so anyone with your public key can confirm it was youWhy it works at all: trapdoor functions, which are easy to compute forwards and infeasible to reverse. RSA leans on the difficulty of factoring a huge number back into two primes; elliptic-curve crypto leans on the discrete logarithm problemRSA versus ECC in practice: RSA-2048 and a 256-bit elliptic curve give comparable security, but the curve key is far smaller and faster, which is why modern systems use Ed25519 for signing and X25519 for key exchangeThe limitation that shapes everything downstream: asymmetric encryption is slow and can only encrypt data smaller than the key, so it is never used for bulk data

Generate a fresh random symmetric key for this message or session, encrypt the actual data with AES, and then encrypt only that small key with the recipient's public keyThe recipient uses their private key to unwrap the symmetric key, then uses it to decrypt the data — fast bulk encryption plus safe key delivery, with neither weaknessThis single pattern is underneath TLS, PGP, encrypted backups, and every end-to-end messenger you have usedThe symmetric key is often called a session key or content key, and it is discarded afterwardsBeing able to say "it is hybrid — asymmetric to move the key, symmetric for the payload" is the difference between reciting buzzwords and understanding the system

Signing, mechanically: hash the message, then transform that hash with your private key. Verifying: hash the message yourself, reverse the signature with the public key, and check the two hashes matchWhat a valid signature proves — the message has not changed (integrity) and it came from the holder of that private key (authenticity). As a side effect the signer cannot credibly deny it (non-repudiation)Which leaves the real problem: a public key is just a blob of bytes, so how do you know it belongs to the person or server you think it does?A certificate is the answer: a public key bundled with an identity (a domain name, say), signed by a Certificate Authority. Your operating system and browser ship with a list of root CAs they already trustThe chain of trust: a root CA signs an intermediate, the intermediate signs the leaf certificate for the site, and your browser verifies each link back to a root it trusts. That is exactly what the padlock means — and exactly why the padlock says nothing about whether the site is honestWhere JWTs fit: HS256 signs with an HMAC and a shared secret (only holders of the secret can verify), while RS256 and ES256 sign with a private key so anyone can verify with the public key and nobody else can forge. That is why identity providers use RS256The practical failure modes: expired certificates, self-signed certificates in development, hostname mismatches, and certificate pinning when you deliberately refuse to trust the general CA system

Diffie-Hellman as a picture first: you and I each start from a shared public colour, each mix in a private colour, and swap the mixtures in the open. We each add our private colour again and land on the identical final colour — which an observer holding both mixtures cannot reproduce, because unmixing paint is hardThe real version: agree on a public base and modulus, each pick a secret exponent, exchange the public results, and each raise the other's result to your own secret. Both sides compute the same shared secret, and it was never transmittedEphemeral Diffie-Hellman (ECDHE) means new throwaway keys for every session, which buys forward secrecy: someone who records today's encrypted traffic and steals the server's private key next year still cannot decrypt itThe TLS 1.3 handshake in order — ClientHello with supported ciphers and a key share; ServerHello with the server's key share; the server's certificate plus a signature proving it holds the matching private key; both sides derive identical session keys; encrypted application data flowsNote what each piece contributes: DH provides the shared secret, the certificate provides identity, and AES-GCM provides the actual encrypted channel. Three separate jobs, three separate mechanismsWhat TLS guarantees: confidentiality and integrity in transit, plus proof of which server you reached. What it explicitly does not guarantee: any protection from that server, which reads everything in plaintext once it arrivesHTTPS is simply HTTP inside TLS — and every cookie flag, CORS rule, and token decision from this phase assumes it is present

Transport encryption protects data between a client and a server. The server decrypts it, reads it, and stores it — which is normal, and required for most product featuresEnd-to-end encryption means the plaintext only ever exists on the participants' own devices. The server stores and forwards ciphertext it structurally cannot read, even if it wanted toThe one-sentence distinction for interviews: HTTPS is encryption in transit with the server inside the trust boundary; E2EE is encryption from person to person with the server deliberately outside itWhat E2EE actually defends against: a breached server, a malicious insider, and a legal demand for stored data — the provider genuinely cannot hand over what it cannot decryptWhat it does not defend against: a compromised device, a screenshot, and metadata — who messaged whom, when, how often, and how large the messages were, all of which the server still seesThe price, and why most products skip it: no server-side search, no server-side previews or thumbnails, much harder moderation and abuse handling, and a genuine key-loss problem where forgetting a password can mean losing data permanentlyWhen it is worth all that: private messaging, health records, password managers, and anything a user would reasonably assume the company cannot read

Setup: each device generates its own keys locally — a long-term identity key pair, a medium-term signed prekey, and a batch of one-time prekeys. Only the public halves are uploaded, so the server holds a directory of public keys and never a private oneStarting a conversation with someone who is offline: fetch their published prekey bundle and run X3DH (Extended Triple Diffie-Hellman), which combines three or four separate DH operations into one shared secret. This is why you can message someone whose phone is offWhy several DH operations rather than one: each pairing contributes a different guarantee — the identity keys authenticate who the parties are, the prekeys provide freshness, and combining them means compromising one key does not hand over the sessionThe Double Ratchet then takes over. A symmetric ratchet derives a brand-new message key for every single message and throws the old one away. A DH ratchet mixes in a fresh key pair each time the conversation turns aroundTwo properties fall out of that: forward secrecy, so a key stolen today cannot decrypt yesterday's messages, and post-compromise security, so once the ratchet turns again the attacker is locked back outVerifying you are talking to the right person: safety numbers or a QR fingerprint compared out of band. This is the only defence against a server that quietly substitutes its own public key — which is why a silent "safety number changed" warning matters and should never be ignoredMultiple devices and groups: every device is a separate recipient with its own session, so a group message is encrypted once per device rather than once per group. That is also why adding a device shows a warning to everyoneThe uncomfortable part nobody has fully solved: backup. Lose the device and you lose the history, unless you add a password-protected encrypted backup — which deliberately reintroduces a weaker link, and is a trade-off you must state openly

The browser already ships the primitives: crypto.subtle.generateKey, deriveKey, encrypt, decrypt, sign and verify — the WebCrypto API, no library required for the basicsTurn the user's password into a key with PBKDF2 or Argon2 in the browser, and never send that derived key or the password-derived material to your serverStore private keys as non-extractable CryptoKey objects in IndexedDB, so your own JavaScript can use them but cannot read the raw bytes out to exfiltrate themThe honest limitation of browser E2EE: your server ships the JavaScript that does the encrypting, so a compromised or coerced server can ship malicious JavaScript tomorrow. Native apps and signed extensions reduce this; a web page cannot eliminate itNever design your own protocol. Use audited primitives (WebCrypto, libsodium) or an audited implementation of an existing protocol — every hand-rolled scheme has been broken by someone with more time than its authorDecide deliberately before you commit: write down every feature your server must still perform (search, previews, moderation, support access, analytics) and check which ones E2EE makes impossible. That list, not the cryptography, is what usually decides the answer

Mini Project

Sealed Whistleblower Drop

Build a sealed source-submission drop where the server stores only ciphertext. Derive a key from a recipient passphrase in the browser with PBKDF2, encrypt each submission with AES-GCM via WebCrypto, and store ciphertext plus IV. Inspect storage to prove the report is unreadable, demonstrate wrong-passphrase failure, and write a threat model covering metadata, malicious client delivery, recovery, search, and moderation tradeoffs.

Day 82: Password Hashing & Storage

A breach exposes every account — including reused onesHash one-way; never decryptWhy salting matters (rainbow tables)

bcrypt: battle-tested, ubiquitousargon2id: modern winner of password hashing competitionCost factor / memory cost: tune so a hash takes ~250msRe-hash on login if cost factor changed

POST /auth/register: hash, store, return safe userPOST /auth/login: fetch, compare, issue session/tokenGeneric error message ("invalid credentials") to prevent enumerationRate limit aggressively

NIST: length > complexity rulesMin 12 chars, allow long passphrasesCheck against known-breached list (haveibeenpwned API)No "must contain symbol" theater

Day 83: Sessions vs JWT

Random session ID in cookie; data on serverexpress-session + connect-mongo or RedisEasy to invalidate (delete from store)Default for traditional web apps

Header.Payload.Signature; statelessPros: no DB lookup per request, multi-serviceCons: revocation is hard, payload visible (not encrypted)Sign with HS256 (shared secret) or RS256 (key pair)

Short-lived access token (15min)Long-lived refresh token (7-30 days, rotated)Refresh stored hashed in DB for revocation

Default to sessions for monolithsDefault to JWT for mobile + multi-serviceNextAuth abstracts both well

Day 84: Cookies Done Right

httpOnly: blocks JS access (XSS protection)secure: HTTPS onlysameSite: lax (default), strict, none (with secure)maxAge / expiresdomain / path scoping

fetch needs credentials: "include"Server cors({ credentials: true, origin: [...] })origin cannot be * with credentials

What CSRF actually is (cross-site form submit)sameSite: lax neutralizes most casesDouble-submit token for state-changing requestscsurf is deprecated; roll your own or use NextAuth

Any XSS = token stolenCookies + httpOnly is dramatically saferMobile apps: secure storage (Keychain/Keystore)

Day 85: Email Verification & Password Reset

Generate cryptographically random (crypto.randomBytes)Store hash in DB, send raw via emailExpiry (1h for reset, 24h for verification)Mark used after consumption

npm install resendVerify domain in Resend dashboard (SPF/DKIM)react-email for nice templatesAlways send via background job in production

POST /auth/verify-email/send → email with linkGET /auth/verify-email?token=... → mark verifiedBlock sensitive actions until verified

POST /auth/forgot → email with link (always 200, no enum)POST /auth/reset → new password + tokenInvalidate all sessions on reset

Day 86: Magic Links & Passwordless

No password = nothing to phish, reuse, or leakLower signup friction, fewer support ticketsThe trade-offs: email deliverability + inbox latencyWhen to offer it alongside vs instead of passwords

Request → generate single-use, short-expiry token → email a login URLStore only the token hash; the raw token lives in the linkVerify → consume token → create session/JWT (reuse the Days 80–81 session and cookie machinery)One-time use + 10-15 min expiry; invalidate on useRate limit requests; generic responses to avoid account enumeration

6-digit code as an alternative to a link (better on mobile)Hash the code, cap attempts, expire fastSame security rules as magic links

Passkeys = phishing-resistant, device-bound credentials (public-key crypto)The register/authenticate ceremony at a high level (no deep dive)Libraries: SimpleWebAuthn; NextAuth/Auth.js has WebAuthn supportWhy you'll add it later, not on day one — but interviewers ask about it

Day 87: OAuth 2.0 Mental Model

Don't ask users for their Google passwordDelegated authorization, not authentication originallyOIDC (OpenID Connect) is the auth layer on top

User clicks → redirect to provider with state + PKCE challengeUser consents → provider redirects back with codeServer exchanges code + verifier for tokensVerify state to prevent CSRF

Scope = what your app may access (email, profile, etc.)Ask for the minimum (least privilege)ID token (OIDC) carries verified user info

Forgetting to verify stateStoring access tokens client-sideTrusting unverified email from providerNot handling provider downtime

Day 88: Wire Google + GitHub OAuth (raw)

Google Cloud Console → OAuth client IDGitHub → Settings → Developer settings → OAuth AppsSet redirect URIs: http://localhost:3000/auth/callback/<provider>Save client ID + secret in .env

arctic: tiny, modern, multi-providerGenerates correct authorize URLs and exchanges codesYou still own the user-creation logic

Verify state cookieExchange code for tokensFetch user info from providerUpsert user in DB; create your own session

Same email from Google + GitHub → linkOr require explicit "link account" action when logged inStore provider + providerAccountId

Day 89: NextAuth (Auth.js v5)

Battle-tested OAuth + credentials + email magic links + passkeysAdapters for every DB: Drizzle/Postgres, Mongo, and othersSession strategies: JWT or DBCSRF and cookie work done right

auth.ts config: providers, adapter (DrizzleAdapter or MongoDBAdapter), callbacksroute.ts handler in /app/api/auth/[...nextauth]middleware.ts to protect routesauth() in server components, useSession in client

session callback: shape what client seesjwt callback: enrich token (e.g., role)signIn callback: gate sign-in (block disabled users)

Add role to User model (Mongo doc or Postgres column)In middleware: redirect non-admins from /adminIn server component: throw notFound() for unauth

Day 90: Authorization (RBAC)

RBAC: role → permissionsABAC: attributes (own resource, time, etc.)Most apps need RBAC + a sprinkle of ABAC ("only the owner can edit")

Verb + resource: post.read, post.write, post.deleteRoles map to sets of permissionsCentralize the can(role, action, resource) check

GET /notes/123 — does it check note.userId === currentUser.id?The #1 bug missed in code reviewAdd an authorize() check in every mutation

Log every privileged action (delete, role change, billing)Append-only collection/tableNever modify or delete audit logs

Day 91: Authorization Design & Threat Modeling

Next.js + NextAuth (Google + GitHub + email magic link)Adapter: Drizzle/Postgres OR Mongo (your choice — you know both)Roles: user, adminPages: marketing, dashboard, admin (gated)Email verification + password reset + magic-link flows

Next.js app with shadcnNextAuth configured with three providers + magic linkDB adapter, env validated by Zod

Public landing pageLogin / signup pagesDashboard skeleton (gated)

Project

Member Access Gateway (rehearsal)

Next.js + NextAuth boilerplate with three providers, magic links, roles, and dashboard. Finished Day 92.

Day 92: Project — Consent-Based Records Release Console

Admin can list/disable usersMiddleware redirects non-adminsServer actions check role before mutating

AuditLog model: actor, action, target, meta, tsHelper logAudit() called in every privileged actionAdmin page to view recent audit entries

Helmet/CSP headers in Next configRate limit auth endpointsVerify cookies are httpOnly + secure in production

Deploy to Vercel with your DB (Atlas or Neon/Supabase)Smoke-test all three providers + magic linkREADME with auth flow diagram

Capstone

Consent-Based Records Release Console — DEPLOYED

Build a clinic console where a patient authorizes a time-bounded records release, staff request scoped access, supervisors approve exceptional access, and every view or export is audited. Use secure sessions, RBAC plus ownership rules, revocation, visible emergency-access disclosure, and deployed OAuth or magic-link sign-in.

Role grants with expiry, request/approve flow, and enforced server-side permissions.
Immutable audit log for grants, revocations, exports, and support impersonation.
Secure session cookies plus one OAuth or magic-link provider.

Phase Complete!

After this phase, you'll be able to:

Explain encoding vs hashing vs encryption, and what SHA-256 actually is
Use symmetric (AES-GCM) and public-key crypto for the right jobs, including signatures and TLS
Describe an end-to-end encrypted system end to end — key exchange, ratcheting, forward secrecy, and its limits
Hash + verify passwords correctly
Pick sessions vs JWT consciously
Ship passwordless: magic links, OTP, and the passkeys/WebAuthn landscape
Cookies with right flags + CSRF awareness
OAuth 2.0 + OIDC mental model
NextAuth v5 with multi-provider, Drizzle/Mongo adapter, RBAC, audit

You can build production auth that wouldn't fail a basic security audit.

Back to all phases

Phase Goal

Day 80: Cryptography from Scratch — Encoding, Hashing & Encryption

Before any crypto: bits, bytes, and what a number like 256 means

Encoding vs hashing vs encryption — the distinction everyone gets wrong

What a hash function actually is

SHA-256: what the name means and what happens inside

What hashes are actually used for

Symmetric encryption: one key, both directions

Encrypt and decrypt something yourself

Chain-of-Custody Crypto Lab

Day 81: Public Keys, Signatures, TLS & End-to-End Encryption

The key-distribution problem and the asymmetric answer

Hybrid encryption: how every real system actually works

Signatures, certificates, and knowing who you are talking to

Diffie-Hellman and the TLS handshake, step by step

End-to-end encryption: what "end" means, and the threat model

The full end-to-end flow, the way Signal does it

Building it in a web app, and when not to

Sealed Whistleblower Drop

Day 82: Password Hashing & Storage

Never store plain passwords

bcrypt vs argon2

Register + login endpoints

Password policy 2026-style

Day 83: Sessions vs JWT

Server sessions

JWT

Access + refresh token pattern

How to choose

Day 84: Cookies Done Right

Cookie flags that matter

CORS + credentials

CSRF

Why NOT localStorage for tokens

Day 85: Email Verification & Password Reset

Single-use tokens

Sending email — Resend

Verify flow

Reset flow

Day 86: Magic Links & Passwordless

Why passwordless is a 2026 default

Magic-link flow, built right

Email/SMS OTP codes

Passkeys / WebAuthn (know the landscape)

Day 87: OAuth 2.0 Mental Model

Why OAuth exists

Authorization Code flow with PKCE

Scopes & ID tokens

Common pitfalls

Day 88: Wire Google + GitHub OAuth (raw)

Register OAuth apps

Use a small library: arctic / openid-client

Callback handler

Account linking

Day 89: NextAuth (Auth.js v5)

Why NextAuth

Setup in Next.js

Callbacks

Roles + protected pages

Day 90: Authorization (RBAC)

RBAC vs ABAC

Designing permissions

IDOR (insecure direct object reference)

Audit logging

Day 91: Authorization Design & Threat Modeling

Spec

Scaffold + NextAuth wired

Marketing + dashboard pages

Member Access Gateway (rehearsal)

Day 92: Project — Consent-Based Records Release Console

RBAC + admin page

Audit log

Security pass

Deploy + capstone

Consent-Based Records Release Console — DEPLOYED

Phase Complete!