JWT None Algorithm Lab: Forge an Admin Token Without a Key

This article explains the JWT none algorithm vulnerability through a practical lab exercise where users forge an admin token by manipulating the algorithm header field. The attack demonstrates how servers that allow tokens to declare their own verification method can be bypassed entirely. The vulnerability remains common in real systems because developers often build custom JWT verifiers that trust the token header instead of enforcing a specific algorithm server-side.

• JWT structure and readabilityA JWT consists of three base64url-encoded parts (header, payload, signature) joined by dots. The header names the signing algorithm, the payload contains claims like username and role, and the signature proves the server issued it. Critically, the header and payload are only encoded, not encrypted, so anyone can read them without the secret key.
• The none algorithm bypass mechanismThe JWT standard defines an algorithm called 'none', meaning 'unsigned', which indicates no signature verification should occur. A vulnerable verifier reads this algorithm from the token header and skips signature checking entirely. An attacker can set the algorithm to 'none', change the role claim to 'admin' in the payload, and append a trailing dot with no signature, and the server will accept it as valid.
• Why signature verification is criticalThe signature is the only protection preventing modification of JWT claims. Once an attacker disables signature verification by switching to the 'none' algorithm, every claim in the payload becomes rewritable. The payload's encoding provides no security—only the cryptographic signature proves authenticity.
• Historical pattern of misimplementationIn 2015, researchers demonstrated that several popular JWT libraries accepted 'alg: none' tokens or could be tricked into verifying with wrong key types because they trusted the header. While libraries were patched (including the Node.js jsonwebtoken library tracked as CVE-2015-9235), the mistake persists in hand-written verifiers, old dependencies, and remains a regular bug bounty finding.
• Server-side algorithm pinning defenseThe core defense is that the server must decide which algorithm verifies tokens, not the token itself. Developers should explicitly pass the expected algorithm to the verify function and reject any token whose header disagrees. Additionally, servers must explicitly reject 'none' for authentication tokens, use maintained libraries kept updated, and validate other claims like expiry, issuer, and audience.
• Payload is signed but not secretDevelopers must understand that the payload is encoded for structure and standardization, not for confidentiality. Any sensitive data placed in a JWT payload should not be considered hidden from attackers, since base64url encoding is trivially reversible. Only the signature provides security guarantees.

Bottom line: The JWT none algorithm vulnerability succeeds because vulnerable servers trust the token header to declare verification settings rather than enforcing a single algorithm server-side; the practical defense is to explicitly pin the expected algorithm in your verify function and reject 'none' outright. This vulnerability persists in real systems despite being known since 2015, making it essential for developers to use maintained JWT libraries, keep them updated, and never implement custom token ver