none: The Unsecured JWT Algorithm

RFC 7515 calls this an Unsecured JWS and the encoding is exactly what it sounds like: header and payload as normal, then a dot and nothing after it. The intended use is a token whose integrity is already assured by the transport or by an enclosing structure, such as a JWT that is itself the payload of a signed or encrypted outer token. Standing alone it asserts nothing whatsoever.

The attack is trivial and it has worked against real libraries. Take a valid signed token, change alg in the header to none, delete the signature, keep the trailing dot, and send it. A verifier that reads the algorithm from the token and dispatches on it will select the none handler, find nothing to check, and report success. The attacker rewrites any claim they like on the way, admin flags included.

The defence is not to blocklist the string none, since case variations and creative encodings have got past exactly that check. The rule is to pin the accepted algorithms in configuration and reject a token whose header does not match, treating the header as a hint about how to check rather than as an instruction about whether to check. Modern libraries refuse none unless it is explicitly enabled, and that setting should stay off.

In the decoder a none token decodes like any other, so the header, payload and claims are all readable. The tool states that there is no signature to verify and its validation list flags the algorithm as none with a warning that the token is unsigned and should not be trusted. Decoding an unsigned token is useful; treating it as evidence of anything is not.