JWT Authentication: Best Practices and When to Use It

A JSON Web Token (JWT) is a standard method for securely transmitting information between parties as a JSON object. Because the information is digitally signed, it can be verified and trusted. JWTs are primarily used in authentication and authorization workflows to provide a self-contained, stateless way to verify identity without requiring constant database lookups.

A signed JWT consists of three distinct parts separated by periods (.):

• Header: Typically consists of two parts: the token type (JWT) and the cryptographic algorithm being used, such as HMAC SHA-256 (HS256) or RSA.
• Payload (Claims): Contains the claims, which are statements about an entity (typically the user) and additional data. These can include registered claims (e.g., sub, iat, exp), public claims, or private claims defined by the application.
• Signature: Used to verify that the sender of the JWT is who they say they are and to ensure that the message was not altered along the way. The signature is created by taking the encoded header, the encoded payload, a secret, and the algorithm specified in the header, then signing it.

To ensure tokens are safe for transport, JWTs utilize base64url encoding. Standard base64 encoding is often unsuitable for web transport because it contains characters like +, /, and =, which are not URL-safe and require percent-encoding in HTTP headers or URIs. Base64url encoding addresses this by replacing the non-safe characters with URL-friendly alternatives and omitting padding characters. This format allows the token to be transmitted seamlessly via:

• HTTP Authorization headers (e.g., Authorization: Bearer <token>)
• URI query parameters
• HTML form data

The resulting string structure is Header.Payload.Signature. By leveraging base64url encoding, developers can safely include these tokens in diverse web environments without risking character corruption or needing to perform additional normalization steps at the application layer.

When a client receives a signed JWT or an opaque refresh token, the browser must persist it until the next authentication request. The two native storage mechanisms are localStorage and sessionStorage. Both expose a simple key‑value API, but they differ in lifespan and scope: localStorage survives browser restarts and is shared across all tabs of the same origin, whereas sessionStorage is cleared when the tab or window closes and is isolated per tab.

• localStorage
  • Convenient for “remember‑me” flows because data persists across sessions.
  • Increases the XSS attack surface: any script that runs in the origin can read the token.
  • Does not mitigate CSRF; the token is sent manually (e.g., in an Authorization header), so CSRF risk is low if the header is required.
• sessionStorage
  • Limits exposure to the lifetime of a single tab, reducing the window for an XSS exploit.
  • Still vulnerable to XSS, but the attacker cannot reuse the token after the tab is closed.
  • Like localStorage, it does not automatically submit with cross‑site requests, so CSRF risk remains minimal.

Because both storages are accessible to JavaScript, they are unsuitable when a strict defense‑in‑depth strategy requires isolation from the DOM. An alternative is to store tokens in HttpOnly cookies, which are inaccessible to JavaScript and thus immune to XSS, but they re‑introduce CSRF concerns unless same‑site attributes and anti‑CSRF tokens are employed.

Refresh tokens should be short‑lived and rotated on each use. Rotation limits the impact of a stolen token because the previous token is invalidated after the first successful refresh. The following practices align with OWASP and NIST guidance:

• Set a modest expiration (e.g., minutes to hours) for the refresh token.
• Store the refresh token in sessionStorage or an HttpOnly cookie with SameSite=Strict.
• On each token refresh, issue a new refresh token and revoke the old one on the server side.
• Log and monitor anomalous refresh patterns to detect token replay attacks.

Example of a safe client‑side refresh flow using sessionStorage:

async function refreshAccess() {
  const rt = sessionStorage.getItem('refreshToken');
  const resp = await fetch('/auth/refresh', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ token: rt })
  });
  const { accessToken, refreshToken } = await resp.json();
  sessionStorage.setItem('accessToken', accessToken);
  sessionStorage.setItem('refreshToken', refreshToken);
}

JSON Web Tokens (JWTs) are self‑contained, signed data structures that travel between a client and a server. Because the payload is only base64url‑encoded, the token is not encrypted; anyone who intercepts it can read the claims unless an additional encryption layer (JWE) is applied. This lack of built‑in confidentiality means that sensitive information such as passwords, personal identifiers, or financial data should never be placed in a JWT payload.

Key technical drawbacks

• Size limits – A JWT includes a header, payload, and signature. Adding many claims (roles, permissions, timestamps, etc.) quickly inflates the token. Large tokens increase request‑header size, can exceed HTTP header limits on some proxies, and add bandwidth overhead for every API call.
• No inherent encryption – The standard only defines signing (JWS). Confidentiality must be added explicitly with JWE, which complicates key management and processing time.
• Stateless revocation difficulty – Because the server does not retain token state, revoking a compromised token requires either short lifetimes with refresh‑token rotation or a token blacklist, both of which re‑introduce server‑side state.
• Complexity in rotation – Managing key rotation for signing algorithms (e.g., HS256, RS256) demands a secure key‑distribution mechanism; a stale key can invalidate all active tokens.

When server‑side sessions are a better fit

• Applications that need to store highly sensitive data (PII, health records) and prefer encryption at rest without adding JWE layers.
• Environments where strict compliance frameworks such as ISO 27001 or NIST require immediate revocation of access after a security event.
• Systems with low‑latency internal networks where the overhead of a database lookup for a session identifier is negligible compared to the cost of transmitting large JWTs.
• Scenarios where the application already maintains a session store (e.g., Redis, Memcached) and can leverage existing session‑management middleware for CSRF protection and idle‑timeout handling.

Practical example

Consider a banking API that returns a JWT containing {"userId":"123","accountNumbers":["A1","A2"],"balance":5000}. The token size exceeds 1 KB, causing the Authorization: Bearer … header to approach typical proxy limits (8 KB). Each request now carries unnecessary data, and any intercepted token reveals account numbers because the token is not encrypted. Switching to a server‑side session that stores only a random session ID (e.g., sid=7f9c3e) eliminates the payload exposure and keeps header size minimal.

In summary, JWTs excel when stateless, short‑lived access tokens are sufficient, but their size, lack of default encryption, and revocation challenges make server‑side sessions the safer, simpler choice for high‑security or compliance‑driven environments.