PASETO vs JWT: A Token Format That Removes the Footguns

JSON Web Tokens are everywhere, and most of their famous vulnerabilities trace back to a single design choice: the token tells the verifier which algorithm to use. PASETO was built by people who got tired of cleaning up after that decision. It is worth understanding even if you never adopt it — because it shows what a token format looks like when security is the default, not a configuration option.

A bearer token is a short string a client presents to prove it is allowed to do something. The server issued it, signed or encrypted it, and trusts it on sight because the cryptography says it has not been tampered with. JSON Web Tokens (JWT) are the dominant format for this, baked into OAuth, OpenID Connect, and countless session systems. PASETO — Platform-Agnostic Security Tokens — is a deliberate alternative, designed by Scott Arciszewski of the Paragon Initiative as a response to the recurring ways JWT implementations get broken.

The two formats solve the same problem. The difference is philosophy: JWT gives you a flexible cryptographic toolbox and trusts you to wield it safely. PASETO hands you exactly one safe option per version and refuses to let you negotiate.

The header is where JWT goes wrong

A JWT carries a header object that declares its own algorithm — {"alg": "RS256"}, for example. The verifier reads that field and uses the named algorithm to check the signature. This is the root of JWT's two most infamous attack classes.

The first is the "none" algorithm. The JWT spec includes alg: none for unsigned tokens. A naive verifier that honors the header will accept a token with no signature at all if an attacker sets alg to none and strips the signature. Whole authentication systems have been bypassed this way.

The second is algorithm confusion. Suppose a server verifies RS256 tokens using an RSA public key — which, being public, is not secret. An attacker changes the header to HS256 (HMAC) and signs the forged token using that public key as the HMAC secret. If the verifier sees HS256 and dutifully runs HMAC with its RSA public key as the key, the signature checks out. The public key was never meant to be a secret, but the token format let it become one.

The core lesson: Both attacks exist because the verifier lets the attacker-supplied token choose the verification algorithm. The cryptographic primitives are fine. The protocol around them hands control to the wrong party.

PASETO's answer: version and purpose, not negotiation

A PASETO looks like v4.public.<payload>.<optional-footer>. The two leading segments are not negotiable algorithm fields — they are a fixed version and a fixed purpose, and the cryptography for each is hard-coded into the library.

• Version pins the entire cryptographic suite. There is no menu. A v4 token uses exactly the v4 primitives.
• Purpose is either local (symmetric authenticated encryption with a shared secret key) or public (asymmetric digital signature, readable by anyone but forgeable by no one).

There is no none. There is no algorithm field for an attacker to rewrite. A v4 verifier configured to accept v4.public tokens will only ever run Ed25519 signature verification; it cannot be tricked into running HMAC because the format gives it nowhere to express that request.

What the versions actually use

PASETO defines paired versions so you can pick a NIST-friendly suite or a modern one:

Version	local (encryption)	public (signature)
v3 (NIST)	AES-256-CTR + HMAC-SHA-384	ECDSA over P-384
v4 (modern)	XChaCha20 + BLAKE2b keyed MAC	Ed25519

The modern v4 suite is the recommended default for new systems. The NIST-based v3 exists for environments with compliance requirements that mandate FIPS-style algorithms. Older v1/v2 versions are deprecated in favor of these two.

Pre-authentication encoding closes the canonicalization gap

Even with a fixed algorithm, signature schemes can be undermined by ambiguity in what gets signed. If a token concatenates several fields before signing, an attacker who can shift a byte from one field into another may produce a different logical message with the same signed bytes — a canonicalization attack.

PASETO addresses this with Pre-Authentication Encoding (PAE): before signing or encrypting, every piece (header, payload, footer, and in v3/v4 an optional implicit assertion) is length-prefixed and packed unambiguously. The signature commits to the exact structure, not just a concatenation, so fields cannot be smuggled across boundaries.

The footer is authenticated but not encrypted — useful for data a verifier needs to read before decrypting, like a key identifier. Anything secret belongs in the payload, never the footer.

So should you switch?

Not reflexively. JWT is not broken when implemented correctly: pin the expected algorithm server-side, reject none, never let the token choose, and use a well-maintained library that does these things by default. Mature ecosystems — OAuth providers, identity platforms — speak JWT, and interoperability is a real constraint. PASETO has fewer libraries and less tooling around it.

PASETO earns its place when you control both ends of the system and want the secure path to be the only path. For internal service-to-service tokens, session tokens in a first-party app, or any greenfield design where you are not bound to an existing JWT consumer, it removes an entire category of misconfiguration. The point is not that PASETO programmers are smarter — it is that the format gives them less rope.

Either way: Tokens are bearer credentials: whoever holds one can use it. Keep lifetimes short, transmit only over TLS, store them where script injection cannot reach them, and have a revocation story. No token format fixes a stolen token.

Originally published at havenmessenger.com