JWT, Login & Session Cookies: A Complete, Modern Guide (2025)

Every web app with a login has to answer the same questions: how do you prove who the user is on each request, how long does that proof last, and how do you take it back? This guide explains server sessions, JSON Web Tokens (JWTs) and the cookie settings that carry them, and gives a secure login, refresh and logout design you can adapt for web and mobile apps.

1. Sessions or tokens?

Session management keeps a user signed in between requests. There are two main ways to do it:

For a server-rendered website, a session cookie is simpler and easier to revoke. JWTs earn their place when several services or a mobile app must verify users without a central store. Many systems combine both.

2. JWT essentials

A JWT is three Base64URL parts joined by dots: header.payload.signature. The payload is encoded, not encrypted: anyone holding the token can read it, so never put passwords, Aadhaar or other personal data in it.

• Claims to include: iss (issuer), aud (audience), sub (user ID), exp (expiry), iat (issued at) and jti (unique token ID for revocation).
• Signing: use an asymmetric algorithm (RS256, ES256 or EdDSA) when more than one service verifies tokens, so verifiers need only the public key. HS256 with a long random secret is fine when one service signs and verifies.
• Key rotation: put a kid (key ID) in the header and publish public keys as a JWKS, so you can introduce a new key before retiring the old one.
• Verification: always pass the expected algorithm, issuer and audience to the library. Never accept alg: none or let the token choose the algorithm.

For the attacks behind these rules (algorithm confusion, weak secrets, replay) and revocation patterns, see JWT security best practices. PASETO is a stricter alternative token format worth considering for new projects.

3. Cookie attributes that matter

Set-Cookie: __Host-session=9f2c…; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600

Set Domain only when subdomains really must share the cookie; leaving it out limits the cookie to the exact host. Safari blocks third-party cookies and Firefox partitions them by default, so design embedded or cross-site flows without relying on them. Partitioned (CHIPS) cookies are the supported option for embedded widgets.

4. CSRF and XSS: the two threats

Cross-site request forgery (CSRF) tricks a signed-in user's browser into sending a request to your site. Defend with SameSite cookies, a CSRF token on every state-changing request, and a check of the Origin header. Don't rely on SameSite alone, especially if you must use SameSite=None.

Cross-site scripting (XSS) runs an attacker's JavaScript on your pages, where it can act as the user even with HttpOnly cookies. Prevent it at the source: escape output by default, set a strict Content Security Policy and keep dependencies updated.

For the CSRF token, a signed double-submit pattern works well with cookie sessions: the server sets a random token, bound to the session and signed with a server secret, in a readable cookie; the front end sends it back in an X-CSRF-Token header; the server checks the signature and that it matches the session.

5. A secure login, refresh and logout flow

Mobile and other non-browser clients send the access token in an Authorization: Bearer header instead, and keep the refresh token in the iOS Keychain or Android Keystore.

6. Example: refresh rotation in Express

A compact TypeScript sketch of step 4. It uses cookie-parser (without it, req.cookies is undefined) and the Node.js built-in crypto module; db stands for your data layer.

import express from 'express';
import cookieParser from 'cookie-parser';
import jwt from 'jsonwebtoken';
import { randomBytes, createHash } from 'node:crypto';

const app = express();
app.use(cookieParser());

const hash = (t: string) => createHash('sha256').update(t).digest('hex');
const cookieBase = { httpOnly: true, secure: true } as const;

async function issueTokens(res: express.Response, userId: string) {
  const access = jwt.sign({ sub: userId }, process.env.JWT_PRIVATE_KEY!, {
    algorithm: 'ES256', issuer: 'https://auth.example.com',
    audience: 'example-web', expiresIn: '10m',
  });
  const refresh = randomBytes(32).toString('base64url');
  await db.refreshTokens.create({ userId, hash: hash(refresh), expiresAt: Date.now() + 30 * 864e5 });
  res.cookie('access_token', access, { ...cookieBase, sameSite: 'lax', path: '/', maxAge: 10 * 60e3 });
  res.cookie('refresh_token', refresh, { ...cookieBase, sameSite: 'strict', path: '/auth', maxAge: 30 * 864e5 });
}

app.post('/auth/refresh', async (req, res) => {
  const token = req.cookies.refresh_token;
  const rec = token && await db.refreshTokens.findByHash(hash(token));
  if (!rec || rec.expiresAt < Date.now()) return res.sendStatus(401);
  if (rec.used || rec.revoked) {                  // reuse: assume theft
    await db.refreshTokens.revokeAllForUser(rec.userId);
    return res.sendStatus(401);
  }
  await db.refreshTokens.markUsed(rec.id);
  await issueTokens(res, rec.userId);
  res.json({ ok: true });
});

Verify access tokens with jwt.verify(token, publicKey, { algorithms: ['ES256'], issuer, audience }). Express's res.cookie takes maxAge in milliseconds.

7. Cross-origin front ends (CORS)

If the front end and API are on different origins, the API must allow that origin with credentials, and the client must opt in:

import cors from 'cors';
app.use(cors({ origin: ['https://app.example.com'], credentials: true }));
// client: fetch(url, { credentials: 'include' })

Never combine credentials: true with a wildcard origin. app.example.com and api.example.com are the same site, so SameSite=Lax cookies still work between them; only a different registrable domain needs SameSite=None; Secure.

8. Security headers and hardening checklist

• Strict-Transport-Security: max-age=31536000; includeSubDomains
• Content-Security-Policy tailored to your app, with frame-ancestors 'none' unless you must be framed
• X-Content-Type-Options: nosniff and Referrer-Policy: strict-origin-when-cross-origin
• Keep signing keys in a secret manager, never in the repository.
• Log sign-ins, failures and password or 2FA changes, and let users see and revoke their active sessions.
• Offer passkeys (WebAuthn) or TOTP 2FA, and use OpenID Connect with Authorization Code + PKCE for "Sign in with…" and mobile apps.

9. Running your app on Domain India

• App Platform: Node.js apps are detected automatically, and other stacks deploy with a Dockerfile. See getting started with the App Platform.
• Shared hosting: cPanel's Node.js tool can run Express apps; see deploying a Node.js app on shared hosting. Free SSL comes with every hosting plan, which the Secure cookie flag needs.
• VPS: self-managed with root access, for your own Redis, database and reverse proxy.

Prices on the cards are live and exclude 18% GST.

Ready to deploy your app? Start with the App Platform, compare VPS plans, or read JWT security best practices next.