Abusing JWTs: Signature Bypass, None Algorithm & Key Confusion

Introduction

JSON Web Tokens (JWTs) are a small, URL-safe method for two parties to exchange claims. JWTs are frequently used for session management and authentication in modern apps because to their adaptability and stateless design. Even with their robust structure and integrated signature verification, JWTs can have major weaknesses if they are not implemented. Vulnerabilities can be used by attackers to raise access, get around authentication, or even create fake tokens. Key confusion attacks, manipulation of the None Algorithm, and Signature Bypass are examples of common misuse tactics that, if left unchecked, can seriously compromise the security of your application.

We’ll discuss three main types of JWT-related vulnerabilities in this blog:

• Signature Bypass via None Algorithm
• Key Confusion Attacks
• Inadequate or Inaccurate Signature Validation

By the conclusion, you’ll know how to identify and address these problems during security assessments.

What Does “Abusing JWTs” Mean?

In this blog, “abusing JWTs” refers to the intentional use of weak or improperly configured JWT implementations to compromise an application’s authorisation or authentication process.

Although JWTs (JSON Web Tokens) are widely used for secure, stateless authentication, they can become dangerous if not implemented correctly. Attackers can manipulate, forge, or tamper with tokens to:

• Avoid using login procedures (for example, by omitting the validation of your signature).
• Increase privileges (for example, by pretending to be an administrator)
• Take advantage of errors in algorithm handling (e.g., moving from RS256 to HS256)
• Brute-force weak secrets and sign their own tokens

Instead than focussing on defects in the JWT standard itself, these abuse tactics take advantage of improper procedures, subpar setups, or out-of-date libraries that developers may unintentionally utilise.

Security testers and developers can better detect vulnerabilities, create more secure authentication systems, and steer clear of typical implementation mistakes by knowing how JWTs can be misused.

JWT Structure Recap

A typical JWT looks like this:

eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eyJ1c2VyIjogImFkbWluIn0.VeryLongSignature

It consists of three base64url-encoded parts:

• Header: algorithm & token type
• Payload: the actual claims (e.g., user role)
• A secret is used to hash the header and payload to form a signature, which guarantees integrity.

Example decoded:

Header: {
  "alg": "HS256",
  "typ": "JWT"
}

Payload: {
  "user": "admin"
}

Signature: HMAC-SHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

1. Signature Bypass via None Algorithm

Vulnerability Summary

Alg: none is a legitimate algorithm that is supported by certain JWT libraries (used for unsigned JWTs). A backend server will completely bypass signature verification if it accepts tokens with alg: none, which is a terrible logical error.

How It Works

An attacker creates a modified token that resembles this after decoding a valid JWT:

Header: {
  "alg": "none",
  "typ": "JWT"
}

Payload: {
  "user": "admin"
}

Then, recombine it without a signature:

Base64(header) + "." + Base64(payload) + "."

Example:

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ.

The attacker will be granted administrator access if the backend regards this token as legitimate and fails to properly enforce signature verification.

Exploitation Tools

• JWT Tool
• Postman with custom headers
• Burp Suite + JWT Editor extension

2. Key Confusion Attack

Vulnerability Summary

When a server utilises the same key for both the HMAC and RSA methods, or misidentifies a public key as a symmetric secret, key confusion develops. This can be used by an attacker to create a legitimate token.

Example Scenario

Let’s say the server expects tokens signed using RS256 (asymmetric). The client never sees the private key; instead, the server uses a public key to validate the signature.

However, if the backend misuses a library that accepts the same public key as a symmetric key, the attacker can:

• Switch to HS256 from RS256 as the algorithm.
• Use the public key as the HMAC secret to forge a token

Exploit in Action

Original token:

Header: {
  "alg": "RS256",
  "typ": "JWT"
}

Modified token:

Header: {
  "alg": "HS256",
  "typ": "JWT"
}

Payload: {
  "user": "admin"
}

• Use the server’s public key (often exposed via .well-known/jwks.json) as the HMAC secret
• Sign the token using HMAC-SHA256
• The server may incorrectly verify the token thinking it’s valid

Real-World Case

This vulnerability was once found in several misconfigured OAuth providers and custom implementations using libraries like jsonwebtoken (Node.js) and older versions of PyJWT.

3. Misconfigured Signature Verification

Common Mistakes

• Failing to validate the token’s signature algorithm
• Not enforcing expected algorithms server-side
• Using weak or guessable secrets
• Accepting tokens without verifying the issuer or audience

Bypassing Signature with Brute Force

Tools like jwt-cracker or JohnTheRipper can brute-force the signature if the secret key is weak.

Example:

jwt-cracker -t token.txt -w /usr/share/wordlists/rockyou.txt

You can increase access and re-sign the token if the key is located.

Detection Tips

When performing a security assessment:

• Intercept JWTs using Burp Suite and decode them
• Remove the signature and change alg to none; check to see if the backend accepts it.
• Try switching from RS256 to HS256 and sign using a known public key
• Use JWT.io Debugger or jwt-tool to tamper with tokens

How to Prevent JWT Abuses

• Always verify the signature server-side; never trust the client
• Reject tokens with alg: none, unless explicitly required (e.g., debugging in development)
• Lock down supported algorithms on the server:

jwt.decode(token, secret, algorithms=["HS256"])  # Don't allow arbitrary alg

• Use different keys for symmetric and asymmetric encryption
• Keep secrets strong and private; don’t hardcode or commit to repos
• Validate claims like exp, iat, aud, iss to prevent replay or misuse

Developer Checklist

Best Practices for JWT Security

1. Use strong algorithms like RS256 or ES256.
2. Validate all JWTs at every service boundary.
3. Reject alg: none explicitly.
4. Separate key types for symmetric and asymmetric algorithms.
5. Implement token expiration and revocation.
6. Log and monitor JWT usage for anomalies.

Conclusion

Unquestionably strong, JWTs provide scalability and flexibility for contemporary authentication systems. But such authority also carries responsibility. Even little setup errors, such accepting the None Algorithm, handling keys incorrectly, which causes Key Confusion, or neglecting to enforce signature checks, can result in Signature Bypass and serious security breaches, as we have witnessed.

Developers and security testers can greatly lower the risk of JWT-based attacks by being aware of the subtleties of Signature Bypass, None Algorithm exploitation, Key Confusion attacks, and weak secret brute-forcing. To transform JWTs from a possible weakness into a safe and dependable authentication method, proper algorithm enforcement, secure key management, and stringent token claim validation are necessary.

By understanding and defending against:

• Signature Bypass via alg: none
• Key Confusion Attacks (RS256 to HS256)
• Weak Secret Brute-Forcing

developers and security testers can significantly reduce the attack surface of their applications.

JWTs need to be utilised carefully because they are not always safe. To transform JWTs from a possible liability into a robust and reliable authentication method, proper algorithm enforcement, stringent key separation, and robust validation logic are essential.

Building and testing safe systems in the real world requires an understanding of these JWT misuse patterns, whether you’re designing secure APIs or doing security audits.

References

• https://portswigger.net/web-security/jwt
• https://github.com/ticarpi/jwt_tool