JWT Authentication: Best Practices, Secure Storage, and When to Use It

A JSON Web Token (JWT) is a compact, URL‑safe string that carries a set of claims between two parties, typically an authentication server and a client. The token consists of three Base64URL‑encoded parts separated by periods:

• Header – a JSON object that declares the token type (typ) and the cryptographic algorithm (alg) used for signing or encryption.
• Payload – the claim set, e.g., user identifier, roles, or expiration time. This is also a JSON object.
• Signature – the result of applying the algorithm from the header to the encoded header and payload, using a secret key (HMAC) or a private key (RSA/ECDSA).

When alg is set to none, the token contains only the header and payload, for example:

eyJhbGciOiJub25lIn0.eyJpZCI6IjEyMyIsIm5hbWUiOiJKb2huIn0

This “unsigned” form is insecure because anyone can modify the payload without detection; there is no cryptographic proof of integrity.

A signed JWT (a JSON Web Signature, JWS) adds the third component. Using HMAC SHA‑256 with a secret key your-256-bit-secret, a typical signed token looks like:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6IjEyMyIsIm5hbWUiOiJKb2huIn0.4SkNQ2QZ8z5Lh7W0n2FK8KnXxXq_9yPmyMslK9YpN0A

The signature is generated by hashing the Base64URL‑encoded header and payload together, then encoding the hash. During verification, the server recomputes the hash with the same secret or public key and compares it to the received signature. If they differ, the token is rejected.

Why signatures matter for authentication:

• Integrity – Any alteration of claims (e.g., changing role from user to admin) invalidates the signature.
• Authenticity – Only parties possessing the signing key can produce a valid signature, establishing trust that the token originated from the authorized server.
• Stateless verification – APIs can validate a token without a database lookup, which aligns with compliance frameworks such as NIST SP 800‑63B that encourage strong, verifiable authentication mechanisms.

In practice, an authentication flow issues a signed JWT after credential verification, stores it (e.g., in localStorage or an HTTP‑only cookie), and presents it in the Authorization: Bearer header on subsequent requests. The server validates the signature on each request, ensuring that the claims have not been tampered with and that the request is truly authenticated.

JSON Web Tokens (JWTs) are signed strings that convey authentication claims. Because the signature can be verified without a server‑side lookup, they are often stored client‑side for subsequent API calls. The storage mechanism determines the attack surface for two primary web threats: cross‑site scripting (XSS) and cross‑site request forgery (CSRF).

XSS impact – any script that runs in the browser can read data from localStorage or sessionStorage. If an attacker injects malicious JavaScript, a token stored there can be exfiltrated and used elsewhere. CSRF impact – cookies are automatically attached to every request to the token’s domain. An attacker who can lure a user’s browser into sending a forged request can cause the server to accept a valid token, unless the cookie is protected with SameSite and CSRF defenses.

Because of these differences, the choice of storage should follow the principle “store where it is least exposed to the relevant threat.”

• httpOnly, Secure, SameSite=Strict/Lax cookies – not accessible to JavaScript, mitigating XSS. Proper SameSite settings reduce CSRF risk. Ideal for short‑lived access tokens.
• Memory (e.g., a JavaScript variable) – token exists only for the page lifecycle, eliminating persistent XSS exposure. Requires re‑authentication on reload, which can be mitigated by a rotation‑based refresh token.
• localStorage / sessionStorage – convenient but fully readable by JavaScript, making them unsuitable for high‑value tokens unless the application is hardened against XSS (e.g., CSP, input sanitisation per OWASP ASVS).

For refresh tokens, rotation is recommended: each time a refresh request succeeds, the server issues a new refresh token and invalidates the previous one. This limits the window of abuse if a token is compromised. A typical flow:

fetch('/auth/refresh', {
  method: 'POST',
  credentials: 'include' // send httpOnly cookie
}).then(r => r.json())
  .then(data => {
    // store new access token in memory
    window.accessToken = data.accessToken;
  });

Token expiration should be short for access tokens (minutes) and longer for refresh tokens (days). Short lifetimes reduce the impact of a stolen token, while rotation ensures that a stolen refresh token becomes unusable after its first use.

Aligning these practices with compliance frameworks (e.g., NIST SP 800‑63B, ISO 27001, SOC 2) satisfies requirements for credential protection, secure session management, and auditability of token issuance and revocation.

Selection Criteria

• Scalability & statelessness: JWTs eliminate the need for shared session stores, which benefits horizontally scaled microservices.
• Revocation & logout: Server‑side sessions allow immediate invalidation; JWT revocation requires short lifetimes, refresh‑token rotation, or a token blacklist.
• Payload size: JWTs carry claims in every request, increasing header size; sessions keep only a small identifier.
• Security surface: Storing JWTs in localStorage or sessionStorage exposes them to XSS, while cookies with HttpOnly and SameSite flags mitigate XSS/CSRF risks per OWASP recommendations.
• Compliance requirements: Standards such as SOC 2, ISO 27001, and NIST SP 800‑63‑3 demand strong session management and auditability; server‑side sessions simplify logging and expiration control.

Actionable Recommendations

• Use JWTs when you need stateless authentication across multiple services and can tolerate short‑lived access tokens (e.g., 15 minutes) combined with securely stored refresh tokens.
• Prefer server‑side sessions for applications that require immediate revocation, fine‑grained audit trails, or where compliance audits demand explicit session lifecycle records.
• If you choose JWTs, store them in HttpOnly cookies to reduce XSS exposure, and implement refresh‑token rotation to mitigate token theft.
• When using server‑side sessions, back the session store with a resilient cache (e.g., Redis) and enforce idle‑timeout and absolute expiration aligned with your security policy.
• Validate JWT signatures on every request, check the exp claim, and reject tokens with mismatched audience (aud) or issuer (iss) values.