1. Concept library
  2. Backend with Node.js
  3. Module 7: Authentication

Concept

Sessions versus tokens

A session stores login state on the server and gives the browser a cookie id; a token, such as a JWT, carries the state itself and the server only verifies it. Each has different revocation, scaling and CSRF properties.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

  1. Explain how a session and a token each carry login state
  2. Compare revocation, scaling and CSRF for sessions and tokens
  3. Spot the long-lived JWT in localStorage

In practice

A few lines that show Sessions versus tokens doing its job.

text
Sessions                         Tokens (JWT)
- state in DB or cache           - state inside the token
- revoke by deleting the row     - revoke only by expiry or a blocklist
- cookie: httpOnly, SameSite     - Authorization: Bearer header
- needs CSRF protection          - no CSRF if not in a cookie
- fits browser apps              - fits APIs and mobile clients

The common mistake

Watch for

Storing a long-lived JWT in localStorage to avoid cookies. Any script injection reads it, and it cannot be revoked. Short-lived access tokens with an httpOnly refresh cookie is the usual compromise.

What to know first

Your roadmap puts these before Sessions versus tokens, unless you already know them.

How it stays learned

Once a session shows you understand Sessions versus tokens, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

  1. Day 3First recall, while it is fresh
  2. Day 7Second, a week on
  3. Day 18Last, when it has settled

Where it leads

Topics that build on Sessions versus tokens.

Previous in the module← Password hashing
Next in the moduleJWT access tokens →