All the reading

Authentication

7 lessons, about 29 minutes. The check's questions come from these.

Planning auth and choosing state

1. Avoid the common auth traps

4 min

Key point

One idea

Auth is not one feature. It is a chain. If one link is weak, the whole sign-in flow becomes easy to break.

Your job is not to invent security. Your job is to use proven tools, make clear choices, and document what you checked.

What goes wrong

Most broken student auth is not broken by advanced hacking. It is broken by simple mistakes: saving plain passwords, trusting the browser too much, leaking secrets, or protecting only the button instead of the server route.

A recruiter inspecting your repo will not expect bank-grade security. They will expect you to know the basic traps and avoid them on purpose.

Common mistake

Common traps

Do not store passwords as plain text. Do not write your own encryption or hashing logic. Do not put API keys, OAuth secrets, JWT secrets, or database URLs in public code.

Do not rely on frontend checks alone. Hiding a dashboard link is not protection. The server must verify the signed-in user before returning private data.

Your to-do

Plan before coding

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

List what users can do before sign-in, like viewing the home page.
List what needs sign-in, like dashboard, profile, orders, or admin pages.
Choose the account method: email and password, OAuth, or both.
Write where secrets will live, usually in environment variables.
Write how you will test logout, expired login, and direct access to protected URLs.

0 of 5 done

2. Hash passwords correctly

4 min

Key point

One rule

Never store a user’s password. Store a slow password hash created by a trusted library.

A password hash is one-way. During login, you hash-check the typed password against the stored hash.

Why slow hashes

Normal hashes like SHA-256 are too fast for passwords. If your database leaks, an attacker can try crores of guesses quickly.

Password hash functions like bcrypt and Argon2 are built to be slow. They also include a unique salt so two users with the same password get different hashes.

Common mistake

Do not do this

Do not encrypt passwords so you can decrypt them later. Your app never needs to know the original password again.

Do not write your own salting or hashing logic. Use a maintained library and store the full hash string it returns.

3. Choose sessions or tokens

5 min

Key point

Main choice

Use sessions for most server-rendered web apps. Use tokens when your API must be called by separate clients like a mobile app, another backend, or a separate frontend domain.

The real question is simple: where will you store the signed-in state, and how will you revoke it when the user logs out?

What sessions mean

With sessions, the server stores the login state. The browser only keeps a random session ID, usually in a cookie.

On each request, the server reads the session ID, looks it up, and knows the user. Logout is easy because the server can delete that session.

What tokens mean

With tokens, the client stores a signed token. The server checks the token on each request and trusts its contents if the signature is valid.

Tokens are common for APIs and mobile apps. Logout is harder because a valid token can remain valid until it expires, unless you add a denylist or use short expiry with refresh tokens.

Your to-do

Cookies and OAuth sign-in

4. Use cookies safely

4 min

Key point

One rule

Treat an auth cookie like a house key. Send it only where needed, hide it from browser JavaScript, and give it an expiry.

The safest default for most college projects is an HttpOnly, Secure cookie with SameSite=Lax and a sensible maxAge.

What flags do

HttpOnly means JavaScript cannot read the cookie using document.cookie. This reduces damage if one page gets an XSS bug.

Secure means the browser sends the cookie only over HTTPS. SameSite controls when the browser sends the cookie during cross-site requests.

Your to-do

Set safe defaults

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Use HttpOnly for any cookie that proves sign-in.
Use Secure in production, because deployed apps should use HTTPS.
Use SameSite=Lax for normal web apps with form sign-in.
Set maxAge or expires so old sessions do not live forever.
Set path to the smallest area that needs the cookie, often /.

0 of 5 done

Protecting routes and shipping repo

6. Protect routes and data

4 min

Key point

The core rule

Protect the server, not just the screen. Hiding a button in React is useful for UX, but it does not stop someone from calling your API with Postman or curl.

Every private route must check who the user is before it reads or writes data.

What to protect

Protect two things: routes and records. A route check asks, “Is anyone signed in?” A record check asks, “Does this signed-in user own this data or have this role?”

For example, /dashboard needs a signed-in user. /api/orders/123 also needs to confirm that order 123 belongs to that user.

Your to-do

Route protection flow

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

10 questions, 7 to pass.

Example

README auth plan

Add a small auth section before you build. It keeps you honest and helps a reviewer understand your choices.

You can ask an AI tool to improve the wording, but check that it does not claim features you have not built.

Auth plan

Public routes:
- /
- /login
- /signup

Protected routes:
- /dashboard
- /profile

Auth method:
- Email and password sign-in
- Passwords will not be stored as plain text
- Secrets will be stored in .env and not committed

Checks before submission:
- A logged-out user cannot open /dashboard directly
- Logout removes access to protected routes
- Invalid login shows a safe error message
- Public repo does not contain real secrets

Example

Node example

This example uses bcrypt in an Express-style app. The same idea applies in Next.js, FastAPI, Django, Rails, or Laravel.

Install with npm install bcrypt. If bcrypt gives install trouble on your laptop, bcryptjs can work for learning, but use bcrypt or Argon2 in serious projects.

import bcrypt from "bcrypt";

const SALT_ROUNDS = 12;

export async function createUser(email, password) {
  const passwordHash = await bcrypt.hash(password, SALT_ROUNDS);

  const user = await db.user.create({
    data: {
      email,
      passwordHash
    }
  });

  return { id: user.id, email: user.email };
}

export async function loginUser(email, password) {
  const user = await db.user.findUnique({ where: { email } });
  if (!user) return null;

  const ok = await bcrypt.compare(password, user.passwordHash);
  if (!ok) return null;

  return { id: user.id, email: user.email };
}

Example

README note

Add a small section like this to your repo. It tells a recruiter that you made an auth design choice, not just copied a package setup.

Auth choice

This app uses server-side sessions.

Reason:
- The app is a normal web app with browser users.
- The backend can store and revoke sessions.
- Logout deletes the server session, so access stops immediately.
- The browser only receives a session id, not the user password or user record.

Security checks:
- Passwords are hashed before storage.
- Protected pages check the session before returning user data.
- Session cookie settings are documented in the cookie section.

Tip

Ask AI well

AI can help you compare choices, but give it your app shape. Ask for risks, not just code.

Check the answer for three things: where state is stored, how expiry works, and how logout or revocation works.

Prompt:
I am building a web app with Express and React for college event registrations.
Users sign in from a browser. The backend and frontend are on the same domain in production.
Should I use server-side sessions or JWT access tokens?
Compare storage, logout, expiry, and what I should write in my README.

Example

Express example

This example sets a session cookie after your login check has already passed. The value should be a random session id or a signed token created by your server.

In local development, Secure cookies may not work on plain http://localhost. Use an environment check, then make sure production uses HTTPS.

app.post('/login', async (req, res) => {
  // 1. Verify email and password first.
  // 2. Create a server-side session or signed token.
  const sessionId = await createSessionForUser(user.id);

  res.cookie('sid', sessionId, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 1000 * 60 * 60 * 24 * 7,
    path: '/'
  });

  res.json({ ok: true });
});

app.post('/logout', (req, res) => {
  res.clearCookie('sid', {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    path: '/'
  });

  res.json({ ok: true });
});

5. Add OAuth sign-in

4 min

Key point

Use a provider

OAuth lets a trusted provider like Google or GitHub confirm who the user is. Your app receives a verified identity and does not see the user’s provider password.

The idea to remember: OAuth is for sign-in delegation. Your app still must create its own app session or token after the provider confirms the user.

What OAuth adds

In a college project, OAuth sign-in is useful because users can join with an account they already have. For a hackathon app, Google is common for student emails. GitHub is common for developer tools.

The flow has four parts: your app redirects to the provider, the user approves, the provider redirects back to your callback URL, and your app signs the user into your own app.

Your to-do

Set up provider app

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Choose one provider first, such as Google or GitHub.
Create an OAuth app in that provider’s developer console.
Add your local callback URL, such as http://localhost:3000/api/auth/callback/google.
Add your deployed callback URL later, using your real domain.
Copy the client ID and client secret into environment variables, not into code.

0 of 5 done

Example

NextAuth example

If your project uses Next.js, Auth.js / NextAuth is a common free choice. This example adds Google sign-in and stores the provider credentials in env vars.

Check the docs for the exact setup for your Next.js version before copying. AI tools often mix old and new NextAuth file paths.

// app/api/auth/[...nextauth]/route.js
import NextAuth from "next-auth";
import GoogleProvider from "next-auth/providers/google";

const handler = NextAuth({
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    }),
  ],
  callbacks: {
    async session({ session, token }) {
      session.user.id = token.sub;
      return session;
    },
  },
});

export { handler as GET, handler as POST };

// .env.local
GOOGLE_CLIENT_ID="your-client-id"
GOOGLE_CLIENT_SECRET="your-client-secret"
NEXTAUTH_URL="http://localhost:3000"
NEXTAUTH_SECRET="make-a-long-random-secret"

Common mistake

Do not trust extras

Do not treat every field from the provider as proof. The email, name, and photo help build a profile, but you should store only what your app needs.

Also do not skip your own auth state. After OAuth succeeds, your app still needs a session cookie or token, with the safe handling from earlier lessons.

Tip

Use AI carefully

Ask AI for a provider checklist, not secret values. Paste your framework version and ask for the correct callback route and env variable names.

Then check three things yourself: secrets are not committed, callback URLs match exactly, and the app creates its own session after provider sign-in.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Pick Google or GitHub as the first OAuth provider for your project.
Create the OAuth app and add the localhost callback URL.
Add client ID, client secret, app URL, and auth secret to .env.local.
Add a Sign in button that starts the provider flow.
Write two README lines explaining why you used OAuth and where the callback is configured.

0 of 5 done

Example

Express middleware

This example assumes an earlier lesson already stored userId in the session after sign-in. The important part is that every private API route uses requireUser before doing work.

function requireUser(req, res, next) {
  if (!req.session || !req.session.userId) {
    return res.status(401).json({ error: "Sign in required" });
  }

  req.user = { id: req.session.userId };
  next();
}

app.get("/api/me", requireUser, async (req, res) => {
  const user = await db.user.findUnique({
    where: { id: req.user.id },
    select: { id: true, name: true, email: true }
  });

  res.json({ user });
});

app.get("/api/projects/:id", requireUser, async (req, res) => {
  const project = await db.project.findFirst({
    where: { id: req.params.id, ownerId: req.user.id },
    select: { id: true, name: true, description: true }
  });

  if (!project) {
    return res.status(404).json({ error: "Project not found" });
  }

  res.json({ project });
});

7. Ship an auth-ready repo

4 min

Key point

Proof beats claims

Your repo should show working auth, not just say it has auth. A recruiter or judge should be able to clone it, add env values, run it, sign in, and see protected routes behave correctly.

Your to-do

Make it runnable

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Commit the app code, lockfile, and clear setup instructions.
Keep secrets out of git and show required env names in a sample file.
Add seed or demo account steps if your app needs test data.
Mention the exact Node, Python, or framework version if setup can break.
Test the clone flow in a fresh folder before submitting.

0 of 5 done

Example

Add env example

Create a sample env file with names only. Never paste real OAuth client secrets, JWT secrets, database passwords, or production URLs with credentials.

# .env.example
DATABASE_URL="your_database_url_here"
SESSION_SECRET="use_a_long_random_secret_here"
GOOGLE_CLIENT_ID="your_google_client_id_here"
GOOGLE_CLIENT_SECRET="your_google_client_secret_here"
NEXTAUTH_URL="http://localhost:3000"

Your to-do

Write the README

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Explain what sign-in methods work, such as email password or Google OAuth.
List which routes are public and which routes are protected.
State where auth checks happen, such as middleware, server routes, or API handlers.
Describe cookie or token handling in plain words.
Add a short security checklist and say what you tested.

0 of 5 done

Example

README auth section

Use direct language. The goal is to help someone inspect your choices fast.

## Auth overview

Sign-in methods:
- Email and password
- Google OAuth

Protected routes:
- /dashboard requires a signed-in user
- /api/notes requires a signed-in user
- /login is public

Security choices:
- Passwords are hashed with bcrypt before storage
- Session is stored in an httpOnly cookie
- Cookie uses secure in production and sameSite=lax
- Server checks the session before returning private data
- Secrets are loaded from environment variables

How to test:
1. Run the app locally
2. Visit /dashboard while signed out. You should be redirected to /login
3. Sign in with a test account
4. Visit /dashboard again. You should see private content
5. Sign out and confirm /dashboard is blocked again

Common mistake

Do not hide gaps

Do not write “secure auth added” if your API routes still return private data without checking the user. Reviewers often test APIs directly, not only pages.

Also avoid committing screenshots that show real user emails, tokens, cookies, or OAuth secrets. Use a demo account and fake data.

Tip

Use AI carefully

Ask ChatGPT, Gemini, or Claude to review your README and test plan. Paste only non-secret code or file snippets.

Check what it returns. It may suggest fake package flags, wrong cookie names, or security claims your app does not actually implement.

Prompt:
Review this README auth section for clarity and missing security checks.
Do not add features I have not implemented.
Point out any claims that need proof in code.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Add .env.example with placeholder values only.
Write the README auth overview, protected routes, and test steps.
Run your app from a fresh clone or fresh folder.
Test signed-out, signed-in, and signed-out-again flows.
Submit the public repo link with screenshots or a short demo note.

0 of 5 done

Authentication

1. Avoid the common auth traps

One idea

What goes wrong

Common traps

Plan before coding

2. Hash passwords correctly

One rule

Why slow hashes

Do not do this

3. Choose sessions or tokens

Main choice

What sessions mean

What tokens mean

4. Use cookies safely

One rule

What flags do

Set safe defaults

6. Protect routes and data

The core rule

What to protect

Route protection flow

README auth plan

Use boring tools

Unsafe errors

Do this now

Signup flow

Node example

What to store

AI check

Do this now

Choose by app shape

Common mistake

README note

Ask AI well

Do this now

Express example

Common mistake

Check in DevTools

CSRF note

Do this now

5. Add OAuth sign-in

Use a provider

What OAuth adds

Set up provider app

NextAuth example

Do not trust extras

Use AI carefully

Do this now

Express middleware

Common leak

Use AI carefully

Do this now

7. Ship an auth-ready repo

Proof beats claims

Make it runnable

Add env example

Write the README

README auth section

Do not hide gaps

Use AI carefully

Do this now