Lion Cipher Lab
Build a PASETO v4 token service from scratch -- and see why it kills JWT's algorithm bugs by design
- Identity & Access Management
- Advanced
- ~75 min
- Free · no account required
Why it matters
JWT's worst wounds are self-inflicted by its own design: it carries the algorithm INSIDE the token, in a header the attacker controls. That single choice spawned two infamous attack classes -- `alg:none` (trick a verifier into accepting an unsigned token) and RS256->HS256 confusion (sign a token with the server's PUBLIC key used as an HMAC secret) -- both documented in the IETF's own JWT Best Current Practices. PASETO's answer is not a better validator; it is a different shape. The version and purpose (`v4.public`) ARE the crypto suite, fixed and out of band, so there is no algorithm field to…
What you'll learn
- implementing PASETO v4.public from scratch
- signing and verifying with Ed25519
- building Pre-Authentication Encoding (PAE) by hand
- base64url (no padding) encoding
- reading the PASETO token wire format
- binding a footer and implicit assertion into a signature
- explaining why PASETO structurally prevents alg:none and RS256->HS256 confusion
- demonstrating a canonicalization/boundary-shift forgery that PAE defeats
- knowing when a JWT is still the pragmatic choice vs when PASETO wins
Steps in this lab
- What you're building, and the one idea it rests on
- Set up: one install, everything else by hand
- The wire format and PAE, before we code it
- Write the token service (the full program)
- Run it and read the real output
- Why JWT's alg:none and RS256->HS256 cannot happen here
- The payoff: PAE catches a forgery a naive verifier accepts
- Judgment: what this token does NOT do, and when to still pick JWT