JWT vs. PASETO: why security teams are retiring JSON Web Tokens

JSON Web Tokens (JWT, RFC 7519) have been the de facto industry standard for stateless authentication in web applications and microservices for over a decade.

However, the core design of JWT contains fundamental cryptographic “footguns”—specifically, allowing the client token to specify the cryptographic algorithm used for verification.

To solve this, modern security engineers and cryptographers have created PASETO (Platform-Agnostic Security Tokens).

JWT HEADER (Vulnerable to Tampering):
{"alg": "HS256", "typ": "JWT"} ➔ Client chooses verification algorithm
Exploits: "alg": "none", Key Confusion (RS256 vs HS256)

PASETO PREFIX (Cryptographically Rigid):
v4.public.ey... ➔ Version and Purpose (Public / Local) fixed by protocol
Enforces: Ed25519 digital signatures and XChaCha20-Poly1305 encryption

---

1. The Critical Security Flaws in JWT

The alg: none Vulnerability

The JWT specification originally permitted an alg: "none" algorithm for unsigned tokens. Poorly configured verification libraries would accept unsigned tokens created by attackers simply by setting alg: "none", completely bypassing authentication.

The Algorithm Confusion Attack (RS256 vs. HS256)

When an application uses asymmetric RSA (RS256), the authentication server signs with a private key, and microservices verify with a public key.

An attacker can take the public RSA key (which is publicly visible), craft a malicious token, and set "alg": "HS256" (symmetric HMAC). If the server library uses the public key string with HMAC verification, the attacker’s forged token succeeds!

---

2. How PASETO Solves This

PASETO eliminates algorithm negotiation completely. Instead of choosing ciphers in the header, a developer selects only two parameters:

1. Version: v4 (Current modern standard)
2. Purpose: local (Symmetric encryption) or public (Asymmetric digital signatures)

┌─────────────────┬──────────────────────┬─────────────────────────────────┐
│ PASETO Mode     │ Cryptographic Cipher │ Primary Use Case                │
├─────────────────┼──────────────────────┼─────────────────────────────────┤
│ v4.local        │ XChaCha20-Poly1305   │ Opaque encrypted session token  │
│ v4.public       │ Ed25519 Signatures   │ Microservice auth verification  │
└─────────────────┴──────────────────────┴─────────────────────────────────┘

---

3. Additional Authenticated Data (AAD)

PASETO tokens support an optional unencrypted footer (e.g. {"kid": "key_2026_09"} for key rotation).

Unlike JWT where header fields can be tampered with without invalidating signatures, PASETO passes the footer as Additional Authenticated Data (AAD) into the cryptographic MAC. Any unauthorized modification to the footer causes token verification to immediately fail.

---

4. Production Security Checklist

1. For New Microservices: Adopt PASETO v4 using standard libraries (such as paseto.js for Node.js, paseto for Go, or pyseto for Python).
2. If Maintaining Legacy JWT Systems:
   • Strictly Whitelist Algorithms: Never allow dynamic algorithm parsing. Explicitly pass algorithms: ['RS256'] into your verifier.
   • Enforce Distinct Keys: Never use the same key material for HMAC and RSA operations.
   • Short Expiration Windows: Keep access token lifespans short (5–15 minutes) combined with rotating refresh tokens.