none
forbiddennoneUnsecured JWT (no signature)
RFC 7519 §6 + RFC 8725 §2.1
⚠ This algorithm is FORBIDDEN in production JWTs.
RFC 8725 §2.1 mandates that servers must never accept JWTs with alg:none.
The none algorithm produces an unsecured JWT with no signature. RFC 7519 §6 defines it, but RFC 8725 §2.1 mandates that servers MUST NOT accept JWTs with alg:none in any security-sensitive context. The classic alg confusion attack: modify a valid JWT's header to alg:none, strip the signature, and some naive implementations accept it. Never implement alg:none acceptance.
Details
The none algorithm was included in RFC 7519 for non-security use cases (plain data encoding). It was quickly identified as a critical security vulnerability when JWT libraries defaulted to accepting it.
The alg:none attack (CVE pattern): 1. Attacker obtains a valid RS256 JWT for a low-privilege user 2. Attacker modifies the header to {"alg": "none"} 3. Attacker modifies the payload (e.g., changes "role": "user" to "role": "admin") 4. Attacker removes the signature portion (keeps the trailing dot) 5. Naive JWT library accepts the token because alg:none is technically valid per RFC 7519
This attack has been used against real-world systems. Multiple CVEs in JWT libraries allowed alg:none bypass.
Mitigation: - Pin the expected algorithm in your JWT verification code. Never read the algorithm from the token header to determine how to verify it. - Reject tokens with alg:none immediately - Use a JWT library that pins algorithms by default (jose, python-jose with algorithms= parameter) - RFC 8725 §2.1 mandates this: "implementations MUST NOT accept unsecured JWTs"
Related: alg confusion attacks (algorithm substitution) - HMAC confusion: attacker changes RS256 to HS256 and signs with the public key as the HMAC secret - Mitigation: never use the same key for different algorithms. Pin expected algorithm in verification.
Key Information
| Key type | None (no key) |
| Key size | N/A |
| Family | none |
| Spec | RFC 7519 §6 + RFC 8725 §2.1 |
Limitations
- !No signature – anyone can forge any payload
- !Classic attack vector (alg:none bypass) with multiple CVEs
- !RFC 8725 explicitly forbids it in security contexts
Valid use cases
No valid security use case. Defined in RFC 7519 for completeness only.