When Should You Really Use JWT? Practical Insights and Common Pitfalls

Basic Concepts: Encoding, Signature, Encryption

JWT consists of three Base64‑encoded parts (header, payload, signature) separated by dots. The header and payload are always Base64‑encoded, while the signature is generated with a cryptographic algorithm such as HS256 (HMAC‑SHA256) using a shared secret.

Encoding and Decoding

Encoding converts binary data to a textual form suitable for HTTP headers or URLs. Because the process is reversible, anyone can decode a JWT to view its payload, which is why sensitive data (e.g., passwords) must never be placed in the payload.

Signature

The signature verifies the token’s integrity and authenticity. The server and issuer share a secret (or a private key for asymmetric algorithms). If the header or payload is altered, the signature verification fails, preventing tampering.

Encryption

Encryption transforms plaintext into ciphertext that can only be read with the appropriate key. JWT does not perform encryption by default; instead, it relies on signatures. RSA can be used for the signature algorithm (e.g., RS256), but RSA encryption and RSA signing are distinct operations.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJxaWFubWlJZCI6InFtMTAzNTNzaEQiLCJpc3MiOiJhcHBfcW0xMDM1M3NoRCIsInBsYXRmb3JtIjoiYXBwIn0.cMNwyDTFVYMLL4e7ts50GFHTvlSJLDpePtHXzu7z9j4

Suitable Scenarios for JWT

One‑time verification, such as email‑activation links that need a user identifier, expiration time, and tamper‑proofness.

Stateless authentication for RESTful APIs where the client and server share a secret and the server validates the token on each request.

Single‑sign‑on and session management (generally not recommended because JWT is not designed for mutable server‑side state).

Token Leakage and Protection

Use HTTPS, set httpOnly=true on cookies, and store JWTs in cookies rather than local storage to mitigate XSS and CSRF attacks. If a token is stolen, the attacker can impersonate the user until the token expires.

Designing the Secret

Instead of a single global secret, consider a per‑user secret so that revoking or rotating a secret only affects that user, reducing the impact of a compromised token.

Logout and Password Change

Because JWTs are stateless, logging out is non‑trivial. Options include:

Clearing the client‑side cookie (only a superficial logout).

Rotating or deleting the user‑specific secret, which invalidates existing tokens.

Storing token identifiers in Redis and checking their presence on each request, effectively turning JWTs into stateful tokens.

When a password is changed, the original JWT remains valid until expiration, so the secret must also be refreshed to force re‑authentication.

Renewal (Refresh) Strategies

Issue a new JWT on every request (simple but performance‑heavy).

Refresh only shortly before expiration.

Use a separate refresh token (OAuth2 style) that can obtain a new JWT without re‑authenticating.

Track JWT expiry in Redis and extend the stored TTL on each access.

Relation to OAuth2 and Session

OAuth2 provides richer flows (client, password, implicit, authorization code) and built‑in support for refresh tokens. JWT can be used as the token format within OAuth2, but when JWT is used alone for session management it loses many advantages of traditional server‑side sessions.

Conclusion

JWT is well‑suited for simple, stateless API authentication with a fixed lifetime, but using it to replace traditional cookie‑session mechanisms introduces risks such as token leakage, logout complexity, and renewal challenges. In most web applications, a conventional session‑based approach remains safer and more feature‑complete.