PASETO vs JWT — Security Comparison
Side-by-side security comparison of PASETO and JWT, covering algorithm confusion, alg=none, key-type confusion, header attacks, and migration considerations.
Detailed Explanation
PASETO and JWT solve the same problem — bearer tokens with claims — but PASETO's design choices systematically eliminate vulnerability classes that have repeatedly affected JWT implementations.
The "alg=none" footgun:
JWT lets the token itself declare its algorithm via the alg header. The most infamous failure mode is {"alg": "none"}, which historically caused some libraries to skip signature verification entirely. PASETO has no alg header — the cryptographic suite is part of the version (v4.public always means Ed25519, period). There is no parsable equivalent of alg=none in PASETO.
Algorithm-confusion attacks:
In JWT, an attacker can sometimes flip an RS256 token to HS256 and trick a poorly-written verifier into using the RSA public key as the HMAC secret. The fix in JWT-land is to constrain accepted algorithms per key, but the foot is still loaded. PASETO eliminates this by versioning: a verifier configured for v4.public will simply reject anything else — there's no key type to confuse.
Key-type confusion:
Same root cause as algorithm confusion, but at the key layer. PASETO requires you to commit to a version+purpose at the verifier level, so the key API physically can't be misused.
Header tampering:
JWT headers are JSON, parsed and trusted before signature verification. CVEs have existed where attackers added jku, x5u, or kid claims pointing to attacker-controlled URLs. PASETO has no parseable header — just the fixed vN.purpose string — so this entire attack surface is gone. kid-style hints, if needed, live in the footer, which is also authenticated.
ISO 8601 timestamps:
JWT timestamps are Unix seconds (NumericDate). PASETO uses ISO 8601 strings. This is more human-readable and avoids the very common bug of mixing seconds and milliseconds.
What JWT still wins at:
Ecosystem and standards alignment. OAuth 2.0, OpenID Connect, and most enterprise identity vendors speak JWT. If you're integrating with those, you generally don't get to pick PASETO. PASETO shines for greenfield, internal token use.
Use Case
A security review recommends PASETO v4.public for a new internal-service token replacing a custom JWT setup, because the JWT verifier accepted multiple algorithms and was at risk of confusion attacks.