The Security Illusion of JWTs

JSON Web Tokens (JWT) are ubiquitous in modern API development. However, their perceived simplicity often masks critical security flaws that expose applications to token forgery, identity theft, and replay attacks.

1. Storing Refresh Tokens in Plaintext

Storing refresh tokens as raw strings in your database is a significant security oversight. If your database is compromised, an attacker can use these plaintext tokens to forge new access tokens at will. This creates a high-impact session hijacking scenario—reminiscent of vulnerabilities in legacy session management systems—where an attacker can maintain persistent access to a user’s account without ever knowing their credentials.

• Fix: Always treat refresh tokens like passwords. Store only their cryptographically hashed versions (e.g., using SHA-256) and validate the incoming token’s hash against the stored value during the refresh flow.

2. Weak Signing Secrets

Using a short or predictable string for your IssuerSigningKey is a catastrophic vulnerability. Attackers can use brute-force tools (like jwt-cracker) to discover the secret and sign their own administrative tokens.

• Fix: Use a cryptographically strong, 256-bit (32 character) minimum secret key, ideally stored in a managed key vault.

3. Storing Sensitive Data in Claims

Remember that JWT payloads are encoded, not encrypted. Anyone with access to the token string can decode it (via jwt.io) and read the claims.

• Fix: Never store passwords, SSNs, or sensitive PII in the token. Only include non-sensitive metadata like sub (user ID) and role.

4. Ignoring Token Revocation

Because JWTs are stateless, there is no built-in way to “log out” a user if their token is compromised.

• Fix: Implement a Token Blacklist (via Redis) or, preferably, utilize Refresh Tokens stored in a secure database. Set the Access Token expiration to a very short duration (e.g., 15 minutes).

5. Not Validating Critical Parameters

Many implementations fail to strictly validate the Issuer, Audience, and Lifetime.

• Fix: Ensure your TokenValidationParameters are configured correctly:

options.TokenValidationParameters = new TokenValidationParameters
{
    ValidateIssuer = true,
    ValidateAudience = true,
    ValidateLifetime = true,
    RequireExpirationTime = true,
    ClockSkew = TimeSpan.Zero // Remove the default 5-minute leeway
};

Security as a Continuous Discipline

The simplicity of JWTs is exactly what makes them dangerous. It’s easy to ship an implementation that “works,” but much harder to ship one that is resilient against a determined attacker. Avoiding these top five mistakes—especially around signing secrets, refresh token storage, and revocation—moves your API from a “good enough” security posture to one that is built on industry-standard defensive patterns. Remember, in security, the smallest oversight is often the largest open door.