Sessions, Auth & Going Live

0 Week at a glance

• Stateless HTTP — the server forgets you the instant a request ends. Sessions & tokens fix that.
• Authentication — proving who you are. Three flavours: Basic, Session, Token.
• Sessions & cookies — the server keeps your data; the browser carries a tiny session id cookie.
• Hashing — never store raw passwords; store a one-way bcrypt hash.
• JWT — a signed header.payload.signature token the client carries instead of a session.
• Deploy — push to GitHub, host on Render, get a live URL. 🎉

1 HTTP forgets everything 🐟

• An interaction is a sequence of requests and responses.
• For each request, the app starts over — no data is kept between consecutive requests.
• It can't tell whether two requests came from the same user or different users.
• So we must transfer data from one request to the next — that's what sessions and tokens do.

Flip the switch and send a few requests. Without a session the server is a goldfish; with one, it remembers you.

2 Authentication — who are you?

3 Basic authentication

• The browser sends the username & password with every single request.
• There's no login or logout system — nothing to start or end.
• It's very insecure: credentials fly across the wire constantly.
• Not used in modern apps because of the security risk.

4 Session authentication

1. The user logs in with a username & password.
2. If login succeeds, the server creates a session id linked to that user.
3. The session id is sent back to the browser and stored in a cookie.
4. On the next request, the browser automatically sends the session id — so the server knows it's you.

Press play and watch the session id travel:

5 Cookies vs sessions

6 The session identifier

• Is generated by the server when a session starts.
• Is remembered by the browser (kept in a cookie).
• Is sent with every further HTTP request to that server.
• Is forgotten when the session ends or the browser is closed.

7 Sessions in Express.js

npm install express-session bcryptjs

Set up the session middleware

const express = require("express");
const session = require("express-session");
const app = express();

app.use(session({
  secret: "your-secret-key",   // signs the session-id cookie
  resave: false,               // don't re-save if nothing changed
  saveUninitialized: true,     // save new, empty sessions too
  cookie: { secure: false }    // true only over HTTPS
}));

• secret — a random string used to sign the session-id cookie so it can't be forged.
• resave — whether to re-save the session on every request even if it didn't change.
• saveUninitialized — whether to store new but empty sessions.
• cookie — configures the cookie (expiry, secure, etc.).

Use the session in your routes

app.get("/login", (req, res) => {
  req.session.username = "Light";        // store data in the session
  res.send("Logged in!");
});

app.get("/profile", (req, res) => {
  const user = req.session.username;      // read it back next request
  res.send(`Welcome, ${user || "Guest"}`);
});

app.get("/logout", (req, res) => {
  req.session.destroy();                  // end the session
  res.send("Logged out.");
});

8 Live session lab 🧪

—

{ }

9 Never store raw passwords — hash them

Type a password and watch its hash. Change one letter — the whole hash changes (the avalanche effect):

That's why we install bcryptjs. You hash on registration and compare on login — never decrypt:

const bcrypt = require("bcryptjs");

// REGISTER — hash the password before saving it
const hash = bcrypt.hashSync("anime123", 10);   // 10 = salt rounds
console.log("stored hash:", hash);

// note: hashing the SAME password again gives a DIFFERENT hash (salt!)
console.log("again:      ", bcrypt.hashSync("anime123", 10));

// LOGIN — compare the typed password against the stored hash
console.log("correct pw →", bcrypt.compareSync("anime123", hash));
console.log("wrong   pw →", bcrypt.compareSync("password", hash));

10 Token authentication

1. Login — the user signs in with credentials once.
2. Receive token — on success, the server issues an auth token.
3. Authenticate — the token is sent on subsequent requests; no password re-entry.
4. Expiration — tokens are time-sensitive and expire after a set period.

Session vs token

11 JSON Web Tokens (JWT)

Forge a token, decode its parts, then tamper with the payload and hit Verify — the signature check catches it:

The jsonwebtoken module

npm install jsonwebtoken

Run it — sign a token, then verify it. Then change the secret in verify and watch it reject the token:

const jwt = require("jsonwebtoken");

const secret  = "supersecret";
const payload = { username: "Light" };

// sign → the string handed to the client after login
const token = jwt.sign(payload, secret, { algorithm: "HS256" });
console.log("Token:", token);

// verify → checks the signature, returns the decoded claims
const decoded = jwt.verify(token, secret, { algorithms: ["HS256"] });
console.log("Decoded username:", decoded.username);

// tamper check — a wrong secret fails verification
try {
  jwt.verify(token, "WRONG-secret");
} catch (e) {
  console.log("Rejected:", e.message);
}

12 Deploying with GitHub

• Store your project online and track changes with version control.
• Connect easily to deployment platforms (like Render).

Before you push, tick the pre-flight checklist (click each item):

• Add a .gitignore that excludes node_modulesDependencies are re-installed by the host — don't commit them.
• Never commit secrets — keep them in .envConnection strings, JWT secrets and API keys stay out of git.
• Read the port dynamically: process.env.PORT || 3000The host assigns a port; hard-coding 3000 breaks deploys.
• Use a cloud database — MongoDB Atlas is onlineA local DB isn't reachable from Render.
• Make sure the project runs locally before pushingIf it doesn't start on your machine, it won't start on theirs.

13 Deploying with Render 🚀

1. Go to render.com and create an account.
2. Click New → Web Service.
3. Connect your GitHub repository.
4. Configure the commands: build npm install, start node app.js.
5. Make sure your MongoDB is online (Atlas) and the port is dynamic.

const PORT = process.env.PORT || 3000;   // Render sets PORT for you
app.listen(PORT, () => console.log("Live on port " + PORT));

Hit deploy and watch Render build your app — it ends with a live URL anyone can visit:

14 Key takeaways

1. HTTP is stateless — each request starts fresh, so we transfer identity with sessions or tokens.
2. Authentication verifies who you are. Basic (creds every request) is insecure; use Session or Token.
3. Session auth: log in once → the server stores a session and the browser holds a session-id cookie it sends every request.
4. Cookies live in the browser (small, user-editable, can be disabled); sessions live on the server (bigger, safe, expire on close).
5. In Express: app.use(session(...)), then read/write req.session; end it with req.session.destroy().
6. Never store raw passwords — hash them with bcrypt (salted, one-way): hashSync to register, compareSync to log in.
7. A JWT is a signed header.payload.signature. jwt.sign() issues it; jwt.verify() checks the signature — tampering is rejected.
8. Deploy: push clean code to GitHub (.gitignore, no secrets, dynamic PORT, cloud DB), connect it on Render, get a live URL. 🚀

15 Self-check quiz

No grades, instant feedback. Ten questions across the whole finale — sessions, hashing, JWT and deployment.

16 Reading & cheat sheet

Grab the Auth & Deploy cheat sheet

🔐 Sessions, JWT & Deploy

Download Open / print

• express-session — docs
• jsonwebtoken — docs · jwt.io (decode real tokens)
• bcryptjs — docs
• Render — deploy a Node/Express app

Guided capstone project