JWT Attacks: None Algorithm, Key Confusion, Claim Tampering

JSON Web Tokens (JWTs) power authentication across millions of web applications, but they're also prime targets for attackers. JWT attacks can completely bypass your security measures, giving hackers unauthorized access to user accounts and sensitive data.

This guide is for developers, security professionals, and anyone working with JWT implementation who needs to understand common attack vectors and how to stop them.

We'll break down three critical JWT attacks that every security-conscious developer should know about. First, you'll learn about the None Algorithm attack, where attackers strip away signature verification entirely. Then we'll explore Key Confusion attacks, which trick applications into using the wrong cryptographic keys. Finally, we'll cover Claim Tampering techniques that let attackers modify token data to escalate their privileges and access restricted resources.

Each attack method comes with real-world examples and practical defense strategies you can implement immediately.

Understanding JWT Vulnerabilities and Their Impact on Application Security

Identifying Common JWT Implementation Weaknesses

Most developers trust that JWT libraries handle security automatically, but this assumption creates dangerous blind spots. Weak secret keys remain the most prevalent issue, with many applications using predictable strings like "secret" or "password123" that attackers can easily brute-force. Default configurations often accept multiple signature algorithms without proper validation, opening doors to algorithm confusion attacks.

Missing expiration claims create tokens that never expire, turning temporary access into permanent backdoors. Applications frequently skip proper audience and issuer validation, allowing tokens meant for one service to work across unrelated systems. Key management becomes another weak link when developers hard-code secrets directly in source code or store them in easily accessible configuration files.

Library misuse compounds these problems. Some implementations accept unsigned tokens when algorithms aren't explicitly validated, while others fail to verify critical claims like token expiration or intended recipients. Race conditions during token validation can also create windows where invalid tokens temporarily pass security checks.

Recognizing Attack Vectors That Exploit Token Validation Flaws

Attackers exploit JWT weaknesses through several well-established methods that target specific implementation flaws. The "none" algorithm attack tricks applications into accepting completely unsigned tokens by setting the algorithm header to "none" when the server doesn't properly validate signature requirements.

Key confusion attacks manipulate the algorithm field to switch between asymmetric and symmetric verification methods. When an application expects RSA signatures but receives HMAC tokens, attackers can sign malicious payloads using the public key as a secret, completely bypassing intended security controls.

Claim tampering represents another common vector where attackers modify payload data without detection. This includes privilege escalation through role manipulation, user impersonation by changing user identifiers, and extending access duration by modifying expiration timestamps.

Brute-force attacks target weak signing secrets, particularly when applications use dictionary words or short random strings. Modern computing power makes cracking poorly chosen secrets surprisingly fast. Additionally, timing attacks can reveal information about secret keys through careful measurement of verification processing times.

Token replay attacks exploit missing or inadequate protections against reused tokens, while injection attacks embed malicious data within JWT claims that downstream services process without proper sanitization.

Assessing Business Risks From Compromised Authentication Systems

Successful JWT attacks cascade into severe business consequences that extend far beyond simple data breaches. Unauthorized access to customer accounts leads to financial fraud, identity theft, and massive regulatory penalties under laws like GDPR and CCPA. Each compromised account represents potential legal liability and mandatory breach notifications that damage corporate reputation.

Privilege escalation attacks create even more devastating scenarios. When attackers gain administrative access through JWT manipulation, they can modify business-critical data, delete records, or install persistent backdoors for future exploitation. The financial impact includes incident response costs, forensic investigations, system rebuilds, and potential ransom payments.

Customer trust erosion follows authentication breaches, resulting in user churn, reduced conversion rates, and negative brand perception that persists long after technical fixes. Public disclosure requirements mean security failures become permanent parts of company history, affecting partnerships, investor confidence, and market valuation.

Operational disruption compounds these problems when compromised systems require emergency shutdowns, affecting revenue streams and service availability. Recovery efforts often demand significant engineering resources, delaying product development and competitive initiatives.

Compliance violations trigger regulatory scrutiny, with financial services, healthcare, and government contractors facing particularly severe consequences, including license revocation, contract termination, and criminal liability for executives. The total cost of JWT-related breaches frequently exceeds millions of dollars when accounting for all direct and indirect impacts.

None Algorithm Attack: Bypassing Signature Verification

Exploiting Unsigned Tokens to Gain Unauthorized Access

The None Algorithm attack represents one of the most dangerous JWT vulnerabilities because it completely eliminates signature verification. When a JWT uses the "none" algorithm, it essentially tells the receiving application to trust the token without any cryptographic validation. Attackers can craft malicious tokens by simply modifying existing ones and changing the algorithm header to "none".

Here's how the attack works: An attacker intercepts a legitimate JWT, decodes the header and payload, modifies the claims (like changing user roles from "user" to "admin"), and then reassembles the token with the algorithm set to "none". Since there's no signature to verify, the application accepts the modified token as authentic.

Real-world examples include attackers escalating privileges by changing user IDs, extending token expiration times, or adding administrative permissions. The attack becomes particularly devastating when applications blindly trust the algorithm specified in the token header without proper validation.

Manipulating Algorithm Headers to Disable Security Checks

JWT headers contain critical metadata that determines how the token should be verified. The "alg" field specifies the cryptographic algorithm used for signing, but poorly implemented applications may accept algorithm changes without question.

Attackers manipulate the algorithm field in several ways:

• Algorithm downgrade: Changing from strong algorithms like RS256 to weaker ones like HS256

• None algorithm injection: Setting the algorithm to "none" to bypass signature verification entirely

• Algorithm confusion: Switching between symmetric and asymmetric algorithms to exploit key handling vulnerabilities

The manipulation process involves decoding the JWT header, modifying the "alg" parameter, and re-encoding the token. Many JWT libraries accept these changes by default, creating security gaps that attackers readily exploit.

Detecting Vulnerable JWT Libraries and Configurations

Identifying vulnerable JWT implementations requires examining both the libraries used and their configurations. Several common indicators signal potential None Algorithm vulnerabilities:

Library-specific vulnerabilities:

• Older versions of popular JWT libraries that accept the "none" algorithm by default

• Libraries that don't validate algorithm types against expected values

• Implementations that allow algorithm switching without proper validation

Configuration red flags:

• Applications that don't explicitly whitelist allowed algorithms

• Systems that trust the algorithm specified in token headers

• Implementations without proper algorithm validation in verification functions

Testing methods:

• Modify existing tokens to use the "none" algorithm and test acceptance

• Check if applications validate algorithm types against the configuration

• Verify that signature verification actually occurs for each supported algorithm

• Test algorithm switching between different token types

Security teams should audit JWT implementations by reviewing library versions, examining configuration files, and conducting penetration testing specifically targeting algorithm manipulation vulnerabilities.

Key Confusion Attack: Exploiting Algorithm Mismatches

Converting Asymmetric Keys to Symmetric for Token Forgery

Key confusion attacks exploit the fundamental differences between asymmetric and symmetric cryptographic algorithms. In asymmetric cryptography, applications use a private key for signing and a public key for verification. However, when an attacker tricks the application into treating the public key as a symmetric secret, they can forge valid tokens.

The attack works by changing the algorithm header from RS256 (RSA with SHA-256) to HS256 (HMAC with SHA-256). Since HMAC uses the same key for both signing and verification, the attacker can use the publicly available RSA public key as the HMAC secret. This creates a scenario where the attacker controls the signing key, completely undermining the security model.

Here's how the conversion process works:

• Extract the public key from the target application

• Convert the key format to match HMAC requirements

• Modify the JWT header to specify HS256 instead of RS256

• Sign the token using the public key as the HMAC secret

• Present the forged token to the application

Leveraging Public Keys as Shared Secrets

Public keys are designed to be openly accessible, making them perfect targets for key confusion attacks. Attackers can obtain these keys through various methods, including certificate transparency logs, application endpoints, or direct certificate inspection.

Once obtained, the public key serves a dual purpose in the attack. The application still believes it's using asymmetric verification, but the modified algorithm forces it to treat the public key as a symmetric shared secret. This misalignment between expectation and reality creates the vulnerability.

Common sources for obtaining public keys include:

• /jwks.json endpoints

• SSL/TLS certificates

• Application documentation

• GitHub repositories

• Certificate transparency databases

The irony lies in the security model itself - public keys are meant to be public, but this openness becomes a weakness when applications don't properly validate algorithm types.

Identifying Applications Vulnerable to Key Type Confusion

Vulnerable applications typically exhibit specific characteristics that make them susceptible to key confusion attacks. The primary indicator is insufficient algorithm validation during token verification. Many JWT libraries accept algorithm specifications from the token header without cross-referencing them against expected values.

Applications using older JWT libraries or custom implementations often lack proper algorithm whitelisting. They might accept any algorithm specified in the header, creating an attack vector. Additionally, applications that dynamically determine verification methods based on token contents rather than configuration are particularly vulnerable.

Red flags include:

Vulnerability Indicator	Risk Level	Description
No algorithm validation	Critical	Accepts any algorithm from the token header
Dynamic key selection	High	Chooses the verification method from the token
Legacy JWT libraries	Medium	Older libraries with known vulnerabilities
Mixed algorithm support	Medium	Supports both symmetric and asymmetric

Testing for vulnerability involves sending tokens with modified algorithm headers and observing the application's response. If the application accepts tokens signed with different algorithms than expected, it's likely vulnerable to key confusion attacks.

Crafting Malicious Tokens Using Incorrect Key Types

Creating malicious tokens requires careful manipulation of both the header and payload sections while ensuring the signature validates under the confused algorithm. The process begins with analyzing the target application's token structure and identifying the current algorithm in use.

The attack payload construction follows these steps:

1. Header Modification: Change the algorithm from RS256 to HS256 while maintaining other header fields

2. Payload Crafting: Modify claims to achieve the desired privilege escalation or access bypass

3. Signature Generation: Use the public key as the HMAC secret to sign the modified token

4. Encoding: Properly base64url encode all components

The most critical aspect involves obtaining the exact public key format expected by the HMAC implementation. Different libraries expect keys in various formats (PEM, DER, JWK), and using the wrong format results in signature verification failures.

Successful token crafting also requires understanding the application's claim validation logic. Attackers often target user identification claims, role assignments, or expiration times to achieve their objectives. The forged token must pass both cryptographic verification and business logic validation to succeed.

Tools like jwt_tool and custom scripts can automate much of this process, but understanding the underlying mechanics ensures more reliable attacks and helps identify edge cases that automated tools might miss.

Claim Tampering: Modifying Token Data for Privilege Escalation

Altering User Roles and Permissions Within JWT Payloads

Attackers often target JWT payloads to modify user privileges directly within the token's claims section. The payload contains critical authorization information like user roles, permissions, and access levels encoded in JSON format. When applications trust these claims without proper verification, attackers can decode the JWT, change values like "role": "user" to "role": "admin", and re-encode the token.

Common targets include:

• Role-based claims (role, user_type, access_level)

• Permission arrays (permissions, scopes, capabilities)

• Group memberships (groups, organizations)

• Feature flags (is_premium, beta_access)

Attackers typically use tools like jwt.io or custom scripts to decode tokens, modify the payload, and create new tokens with elevated privileges. The success of this attack depends entirely on whether the application validates the token's signature properly.

Extending Token Expiration Times to Maintain Persistent Access

Token expiration manipulation allows attackers to maintain unauthorized access beyond intended timeframes. The exp claim in JWTs specifies when a token expires, typically as a Unix timestamp. Attackers modify this value to extend their access window significantly.

Popular manipulation techniques include:

• Setting expiration dates far into the future (years ahead)

• Removing the exp claim entirely if the application doesn't enforce it

• Modifying iat (issued at) claims to make tokens appear freshly issued

• Adjusting nbf (not before) claims to activate tokens prematurely

This attack proves particularly dangerous in environments where tokens grant access to sensitive resources or administrative functions. Attackers can maintain persistent backdoors even after legitimate users change passwords or administrators revoke access through other means.

Injecting Malicious Claims to Bypass Authorization Controls

Custom claims injection exploits applications that make authorization decisions based on specific JWT claims. Attackers add new claims or modify existing ones to bypass security controls that weren't designed to handle manipulated tokens.

Examples of malicious claim injection:

• Adding "is_verified": true to bypass email verification requirements

• Inserting "subscription_tier": "enterprise" for premium feature access

• Creating "bypass_mfa": true to skip multi-factor authentication

• Injecting "debug_mode": true to access development features

Applications that rely on claims-based authorization without proper signature validation become vulnerable to this attack vector. The malicious claims blend seamlessly with legitimate ones, making detection challenging without comprehensive logging.

Exploiting Weak Claim Validation Logic

Poor claim validation creates opportunities for sophisticated attacks that go beyond simple value modifications. Applications often implement insufficient checks on claim formats, data types, or logical relationships between claims.

Vulnerable validation patterns include:

• Accepting string values where integers are expected ("user_id": "1 OR 1=1")

• Missing null or empty value checks on critical claims

• Inadequate range validation on numeric claims

• Trusting client-controlled timestamps without verification

Validation Weakness	Attack Vector	Potential Impact
Type confusion	String injection in numeric fields	SQL injection, logic bypasses
Missing bounds checking	Negative user IDs, extreme timestamps	Access to unauthorized data
Insufficient sanitization	Special characters in string claims	XSS, command injection
Logic flaws	Contradictory claims accepted	Authorization bypasses

Attackers exploit these weaknesses by crafting tokens with unexpected claim values that trigger application vulnerabilities. The combination of weak validation and modified claims creates a powerful attack surface that can compromise entire application security models.

Defending Against JWT Attacks Through Secure Implementation

Implementing Robust Algorithm Validation and Whitelisting

Creating a secure JWT implementation starts with strict algorithm validation. Your application should never accept tokens without verifying the algorithm specified in the header matches your expected values. Establish an explicit whitelist of acceptable algorithms - typically just one or two that your system actually uses.

When processing incoming tokens, reject any JWT that specifies algorithms outside your whitelist immediately. This prevents attackers from exploiting the "none" algorithm vulnerability or forcing your system to use weaker cryptographic methods. Your validation logic should fail securely - if algorithm verification fails, deny access completely rather than proceeding with warnings.

Consider these essential validation rules:

• Never accept tokens with the "none" algorithm unless explicitly required for testing

• Maintain separate whitelists for different token types (access tokens, refresh tokens)

• Log rejected tokens for security monitoring and incident response

• Implement algorithm validation before any other token processing

Enforcing Proper Key Management and Separation Practices

Key management forms the backbone of JWT security. Asymmetric key confusion attacks succeed when applications mix up public and private keys or fail to properly validate which key type they're receiving. Implement strict key type validation to prevent these attacks.

Store your signing keys securely using dedicated key management services or hardware security modules when possible. Separate your signing and verification processes clearly - signing operations should only access private keys, while verification should only use public keys. This separation makes it impossible for attackers to trick your verification process into accepting maliciously crafted tokens.

Key rotation practices deserve special attention. Regularly rotate your signing keys and maintain a secure distribution mechanism for public keys. When rotating keys, ensure your verification process can handle tokens signed with previous keys during the transition period, but set clear expiration windows to prevent indefinite use of compromised keys.

Key Management Checklist:

Practice	Implementation
Key Storage	Use dedicated key management services
Key Rotation	Implement automated rotation every 90 days
Key Access	Restrict private key access to signing services only
Key Validation	Verify key type matches expected algorithm

Validating All Claims with Strict Security Checks

Proper claim validation goes beyond checking expiration times. Every claim in your JWT requires validation against your application's security requirements. Start with standard claims like iss (issuer), aud (audience), and exp (expiration), But don't stop there.

Implement comprehensive validation for custom claims that control user permissions and access levels. When users present tokens claiming administrative privileges, verify these claims against your user database or directory service. Never trust claim values without independent verification, especially for sensitive operations like account modifications or data access.

Time-based claims need special handling. Check nbf (not before) and iat (issued at) claims to prevent token replay attacks and ensure tokens aren't being used outside their intended timeframe. Build in clock skew tolerance - typically 30 seconds - to handle minor time differences between systems.

Your validation process should also verify claim formatting and data types. String claims should match expected patterns, numeric claims should fall within acceptable ranges, and boolean claims should only accept true boolean values. This prevents attackers from exploiting loose parsing logic to inject malicious data through claim manipulation.

Remember that claim validation happens on every request, so optimize your validation logic for performance while maintaining security. Cache validation results when appropriate, but always revalidate security-sensitive claims that could change between requests.

JWT attacks pose serious threats to web application security, and understanding these vulnerabilities is the first step toward building stronger defenses. The None Algorithm attack can completely bypass signature verification, while Key Confusion attacks exploit mismatches between signing and verification algorithms. Claim Tampering allows attackers to modify critical token data, potentially leading to unauthorized access and privilege escalation.

Protecting your applications requires a proactive approach to JWT implementation. Always validate algorithms explicitly, never allow the 'none' algorithm in production environments, and implement robust claim validation on every token. Regular security audits and staying updated with the latest JWT security best practices will help keep your applications safe from these common but dangerous attack vectors.