JWT vs Session Tokens: Key Differences, Security Trade-offs, and When to Use Each

How each model works

The fundamental difference is where user state lives: a session keeps it on the server and gives the client only a reference, while a JWT puts the state itself inside the token the client carries.

Side-by-side comparison

What is inside a JWT

A JWT is three base64url-encoded JSON objects joined by dots: header.payload.signature. The header names the algorithm; the payload carries the claims; the signature is computed over the header and payload so any tampering invalidates the token.

# Decode a JWT without a library (Python)
import base64, json

token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTc1MDAwMDAwMH0.SIGNATURE"

header_b64, payload_b64, sig = token.split(".")

def decode_part(b64):
    # JWT uses unpadded base64url — add padding back
    pad = 4 - len(b64) % 4
    return json.loads(base64.urlsafe_b64decode(b64 + "=" * pad))

print(decode_part(header_b64))
# {'alg': 'HS256', 'typ': 'JWT'}

print(decode_part(payload_b64))
# {'sub': 'user_123', 'role': 'admin', 'exp': 1750000000}
# Anyone with the token can read this — it is NOT encrypted

You can also paste any JWT into the JWT Decoder to inspect its claims and expiry instantly.

Creating a JWT in Node.js

You issue a JWT with jwt.sign() and verify it with jwt.verify() from the jsonwebtoken package. Signing happens once at login; verification runs on every protected request and throws if the token is expired or tampered with.

const jwt = require("jsonwebtoken");

const SECRET = process.env.JWT_SECRET; // keep this secret!

// Sign — issued at login
function issueToken(userId, role) {
  return jwt.sign(
    { sub: userId, role },
    SECRET,
    { algorithm: "HS256", expiresIn: "15m" }
  );
}

// Verify — called on every protected request
function verifyToken(token) {
  try {
    return jwt.verify(token, SECRET); // throws if expired or tampered
  } catch (err) {
    return null; // treat as unauthenticated
  }
}

const token = issueToken("user_123", "admin");
const payload = verifyToken(token);
console.log(payload.sub); // "user_123"

Session-based auth in Node.js (express-session)

Session auth stores state server-side in a shared store like Redis and tracks the user with a signed cookie. Logging out is a single req.session.destroy() call — the record is deleted and the token is instantly invalid, which is the capability JWTs lack.

const express = require("express");
const session = require("express-session");
const RedisStore = require("connect-redis").default;
const { createClient } = require("redis");

const app = express();
const redisClient = createClient();

app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,    // not accessible via JS
    secure: true,      // HTTPS only
    sameSite: "strict",
    maxAge: 24 * 60 * 60 * 1000  // 1 day
  }
}));

app.post("/login", (req, res) => {
  // after validating credentials...
  req.session.userId = "user_123";
  req.session.role = "admin";
  res.json({ ok: true });
});

app.post("/logout", (req, res) => {
  req.session.destroy(); // instantly revoked
  res.clearCookie("connect.sid");
  res.json({ ok: true });
});

The revocation problem with JWTs

The hardest part of JWT-based auth is logout. Because the token is self-contained, a server cannot "delete" it — it remains valid until its exp claim passes. The standard workarounds:

• Short expiry + refresh tokens — access tokens expire in 5–15 minutes; a long-lived refresh token (stored in the database) issues new access tokens. Revoking the refresh token effectively logs the user out within one expiry window.
• Token blacklist (denylist) — on logout, store the token's jti (JWT ID) in Redis with a TTL equal to the token's remaining lifetime. Check the denylist on every request. This reintroduces server state but keeps the verification path fast.
• Very short expiry, no refresh — for low-risk contexts, an expiry of 1–5 minutes means a stolen token is quickly useless. Only practical when the client re-authenticates silently.

HS256 vs RS256: which signing algorithm to use

HS256 uses a single shared secret. Any service that verifies tokens must hold the secret — a leak compromises the entire system and all services must rotate keys together.

RS256 uses an asymmetric key pair. The auth server signs with the private key; all other services verify with the public key. The public key can be published openly (via a JWKS endpoint) without any security risk. This is the right choice when multiple services or third parties verify your tokens.

# RS256 signing in Python with PyJWT
import jwt
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.backends import default_backend
from pathlib import Path

private_key = serialization.load_pem_private_key(
    Path("private.pem").read_bytes(),
    password=None,
    backend=default_backend()
)
public_key = serialization.load_pem_public_key(
    Path("public.pem").read_bytes(),
    backend=default_backend()
)

# Auth server — signs with private key
token = jwt.encode({"sub": "user_123", "role": "admin"}, private_key, algorithm="RS256")

# Any service — verifies with public key (never sees private key)
payload = jwt.decode(token, public_key, algorithms=["RS256"])
print(payload)  # {'sub': 'user_123', 'role': 'admin'}

Where to store a JWT in the browser

The safest place to store a JWT in the browser is an HttpOnly, Secure, SameSite=Strict cookie — not localStorage. Token storage is the most debated JWT question; here are the two options and their trade-offs:

An HttpOnly cookie with Secure; SameSite=Strict gives you the best of both worlds — it is not readable by JavaScript (no XSS exfiltration) and is not sent on cross-site requests (no CSRF). At the transport and storage level, security becomes comparable to a session cookie — but the two are not fully equivalent: a session can still be revoked centrally by deleting the server record, whereas a JWT’s security continues to depend on its token-lifecycle design (short expiry, refresh rotation, and any denylist you maintain).

When to use sessions vs JWTs

Choose by your revocation needs and how many independent services must verify identity. Use this if/then table as a quick decision rule:

How to choose between JWT and session tokens

Work through these five steps in order — each one narrows the decision:

1. Assess revocation requirements. If users must be able to log out instantly and have their access revoked immediately (e.g. banking, healthcare, admin tools), use sessions — they can be deleted from the server store the moment logout happens. JWTs cannot be revoked without additional infrastructure.
2. Evaluate your deployment topology. If you run many stateless API server instances behind a load balancer and want to avoid a shared session store, JWTs reduce infrastructure coupling. If you already run Redis or a database for other reasons, a session store adds negligible cost.
3. Consider client diversity. If multiple clients — mobile apps, third-party services, microservices — need to verify user identity without calling back to the auth server, JWTs are the natural fit. Bearer tokens in Authorization headers work across any HTTP client.
4. Choose a signing algorithm. For a single-service app use HS256 (simpler). For microservices where multiple services verify tokens, use RS256 — services hold the public key and never touch the private key. Avoid the none algorithm, and always validate the alg header.
5. Set expiry and rotation policy. Short-lived access tokens (15 minutes) with a refresh token pattern give the best security-to-convenience ratio for JWTs. Sessions should have an idle timeout and an absolute maximum lifetime. Rotate refresh tokens on every use (refresh token rotation) and revoke the family on reuse detection.