Session or JWT: how a site recognizes you from page to page

You log in once, then move from page to page without typing your password again. The site recognizes you through a session or a JWT: two ways of keeping proof that you are who you say you are.

Why a memory is needed

The web "forgets" everything between two requests: each page you ask for is handled as if the site had never seen you. To avoid asking for your password on every click, the site hands you something to show next time.

The session: the cloakroom ticket

You drop off your coat and receive a numbered ticket. The ticket says nothing about you: it is the cloakroom that knows, in its register, who it belongs to.

• The server creates a session, stores it in its register, and sends you an identifier (often in a cookie).
• On each request, it finds your session thanks to that identifier.
• Upside: to log someone out, just cross their line out of the register.
• Trade-off: the server has to keep that register.

The JWT: the sealed badge

A JWT (JSON Web Token) works like a badge that already contains your details (who you are, until when), with a seal that only the server can apply. To check it, the server verifies the seal: no register needed.

• Upside: handy when several services must recognize you without all consulting the same database.
• Trade-off: until it expires, the badge stays valid. Revoking it early is harder.
• Careful: the content is signed, not hidden. Never put confidential information in it.

Good habits, whichever you pick

• Give the badge or session a short lifetime, and renew it.
• Store it in a protected cookie (flagged HttpOnly, so page scripts cannot read it), rather than somewhere any script can read.
• Serve everything over HTTPS.
• Keep the secret that seals JWTs on the server, like any other key.

Which one?

For a product with a single application and a single server, the session is usually the simplest and the easiest to revoke. JWTs make sense when the architecture calls for them. Both are very easy to misconfigure: the choice matters less than the care taken.

Key takeaway

Session: the server remembers you. JWT: you carry your own proof. Either way: short lifetime, protected cookie, HTTPS.

And for your product?

Many quickly generated or inherited applications handle login their own way, without anyone having reviewed it. A code audit of your application looks precisely at how your users are recognized and protected. We can talk about it in a 30-minute conversation.

Also worth reading: password hashing, OAuth, or "sign in with Google" and XSS.