JWT: Convenient but Risky? The Problem with JWT Explained

If you’ve ever followed online tutorials for building projects, you’ve likely encountered JSON Web Tokens (JWT) being used frequently. But have you ever wondered—is JWT actually safe?

Despite its widespread usage, many developers caution against relying on JWT for authentication. Why is that? In this article, we’ll break down what JWT is, explore its advantages and disadvantages, and discuss why many experts recommend against using it for session management.

What is JWT?

Before diving into the concerns, let’s start with the basics.

• JWT stands for JSON Web Token.
• It is essentially a JSON-based token that allows data to be verified and trusted without requiring a database lookup.
• JWT is commonly used for authentication and securely exchanging information between parties.

The official website provides more details: JSON Web Tokens — jwt.io

How JWT Works

Here’s a simplified explanation of the JWT authentication process:

1. User Logs In: When a user logs into a website, the server generates a JWT and sends it to the user.
2. Token as an Identity Proof: The JWT contains key identity information like the user’s ID, roles, and permissions.
3. User Makes Requests: Every time the user interacts with the website, they send this JWT along with their request.
4. Server Verification: The website verifies the JWT’s signature to ensure it was issued by a trusted source and checks the stored information.
5. Access Granted or Denied: If the JWT is valid, the user is granted access; otherwise, they are denied.

JWT is attractive because it provides a stateless authentication mechanism—once issued, the token can be used without referring back to the database.

Why is JWT Considered Problematic?

While JWT has its advantages, it also comes with several major drawbacks. Let’s explore these issues step by step.

1. Size Overhead

One of JWT’s biggest drawbacks is its size.

Consider a simple user ID, such as “bob”:

• If stored in a cookie, it would be just 5 bytes.
• If stored in a JWT, the size increases approximately 51 times due to the additional metadata and encryption.

Larger payloads mean higher bandwidth usage and slower performance, making JWT inefficient for systems with high traffic.

2. Redundant Signatures

JWTs are designed to be self-contained and use signatures for validation. However, modern web frameworks already provide secure, signed session cookies by default.

• Many frameworks automatically sign and encrypt cookies, ensuring authenticity.
• When using JWTs in session cookies, you end up with two layers of signatures—one on the JWT itself and another on the cookie.
• This redundancy adds unnecessary complexity without providing significant security benefits.

3. Token Revocation Issues

Unlike traditional session cookies, JWTs cannot be easily revoked once issued. This poses several security risks:

Logging Out Doesn’t Truly Log You Out

Imagine a user logs out of their account. Normally, this should invalidate their session immediately. However, with JWT, the token remains valid until it expires.

• If an attacker gains access to the JWT before it expires, they can continue making requests as the user.
• The only way to revoke a JWT is to maintain a token blacklist, which contradicts the “stateless” design of JWTs and adds complexity.

Delayed Permission Updates (Stale Data)

Consider a scenario where an administrator is downgraded to a regular user. If the admin’s JWT is still valid, they retain admin privileges until the token expires, creating a security loophole.

4. Security Vulnerabilities

JWTs Are Often Not Encrypted

JWTs are encoded, not encrypted. This means that anyone with access to the token can decode it and read the contents.

• If the JWT is intercepted by an attacker, they can extract user details and permissions.
• Without additional encryption, sensitive information within the token is exposed.

Susceptibility to Man-in-the-Middle (MITM) Attacks

JWTs are usually stored in local storage or cookies. If stored in local storage, they are vulnerable to Cross-Site Scripting (XSS) attacks. If stored in cookies, they are susceptible to Cross-Site Request Forgery (CSRF) attacks unless properly secured.

When is JWT Useful?

Despite these issues, JWT still has valid use cases.

JWT is good for:

✔ One-time authorization tokens – Used for short-term operations, such as API authentication between services.
✔ Stateless microservices – In microservices architectures, JWTs help transfer identity claims without requiring centralized authentication lookups.
✔ Third-party authentication – Used in OAuth2 implementations for verifying identities.

JWT is NOT good for:

✖ User session management – Traditional session cookies are more secure and efficient.
✖ Long-term authentication – Once issued, a JWT cannot be revoked until it expires.
✖ Frequent user interactions – The size overhead becomes inefficient compared to lightweight session tokens.

Conclusion: Should You Use JWT?

JWTs serve a purpose but are not an ideal solution for user session management. Their size, revocation issues, and security risks make them impractical compared to traditional session cookies.

Instead, well-established session-based authentication mechanisms provide a more reliable and secure approach.

That being said, JWT is still valuable for specific use cases, particularly in API authentication and microservices. However, if you’re building a web application and need a session-based authentication system, stick with session cookies—they’re faster, more secure, and easier to manage.

If you’re experimenting with JWTs for learning purposes, go ahead! But for production systems, consider the risks carefully and opt for a safer alternative when handling user sessions.