Why I'm Finally Ditching JWT for PASETO (And Why You Should Care About paseto-kit)

Last month, I inherited a Node.js backend where the previous team had implemented JWT token validation in three different ways across the codebase. Three. Different. Ways. One dev used the verify() without checking the algorithm claim, another hardcoded HMAC when the keys were asymmetric, and a third just... didn't validate expiry. None of them were intentionally malicious—they just picked JWT and assumed it was secure by default. It isn't.

That experience stuck with me because it revealed something about JWT that everyone knows but nobody talks about: the spec is designed to let you shoot yourself in the foot. Algorithm confusion attacks, implicit defaults, versioning nightmares—JWT solved a problem in 2010, but the problem it solved wasn't actually security. It was just convenience. When I discovered PASETO a year ago, it felt like finding the thing JWT should have been all along.

But here's the catch: implementing PASETO in JavaScript has been a mess. The reference implementation got archived, the remaining libraries were incomplete, and key serialization was a black hole. That changed recently with paseto-kit, and I think it's worth understanding why this matters, especially if you're building anything remotely sensitive.

Understanding PASETO vs JWT (And Why the Difference Matters)

PASETO is explicitly designed as a secure JWT alternative, not just a rebrand. The differences are architectural, not cosmetic.

JWT gives you algorithm negotiation—you tell it what algorithm to use, and it trusts you. PASETO versioning means each version bundles a specific, audited cryptographic stack. You can't negotiate yourself into using MD5 as your hash function because PASETO v4 just is XChaCha20 + BLAKE2b for symmetric encryption, and Ed25519 for public-key operations. That's it. No options. No footguns.

The other thing that sold me: PASERK, the key serialization standard that PASETO brings along. Managing cryptographic keys is genuinely hard, and I've seen too many projects roll their own key wrapping logic or just store raw keys in environment variables and call it secure. PASERK handles local key wrapping, password-based key derivation, sealed key encryption—the whole lifecycle. It's boring infrastructure that should exist in every token library but mostly doesn't.

What paseto-kit Actually Brings to the Table

When I read about paseto-kit, I immediately looked at what it covers: both PASETO v3 (NIST-compliant, for compliance-heavy environments) and v4 (modern crypto), with full PASERK support including all 11 key types, password wrapping with Argon2id, and seal operations.

More importantly, it's runtime-agnostic. One codebase, no special Node.js imports, works in Deno, Bun, browsers, and edge runtimes. That's the detail that changed my mind about switching. I run workloads across multiple runtimes now, and the friction of rewriting auth logic for each one has been real. With paseto-kit, I don't have that problem.

The implementation approach also resonates with me: they use audited primitives from @noble/* and test against official PASETO test vectors, including the adversarial ones. No novel cryptography means fewer things to get wrong. I've learned through painful experience that being boring in crypto is a feature, not a limitation.

My Take: Ready, But Not Without Caution

Here's what I appreciate: the authors are honest that this is pre-1.0 and lacks a formal security audit. That's the kind of transparency that actually builds trust. Too many libraries ship with confidence they haven't earned.

Would I use this in production today? Cautiously. For new projects where I control the stack, absolutely. For existing JWT implementations, I'd be more deliberate—migrating token infrastructure isn't trivial, and the benefit needs to justify the migration cost.

My one question: how does the v3/v4 distinction play out in practice for teams? If you're using v4 and need to migrate to a FIPS environment, can you run both versions simultaneously, or does that invite its own security headaches?

A Practical Example

import { generateKeyPair, sign, verify } from 'paseto-kit';

const { secretKey, publicKey } = generateKeyPair();
const token = sign(secretKey, { 
  userId: 'user123', 
  role: 'admin',
  exp: new Date(Date.now() + 3600000) // 1 hour
});

// Verification with built-in claim validation
const { payload } = verify(publicKey, token, { 
  validate: { exp: true, iss: 'my-app' } 
});

console.log(payload.userId); // user123

This is exactly what JWT should have been by default: strong validation, explicit expiry handling, zero algorithm surprises.

What's Next

If you're managing auth in JavaScript right now, spend an hour reading the PASETO spec and looking at paseto-kit. Even if you don't switch immediately, understanding why PASETO exists will make you a better judge of your current security posture.

Have you run into JWT vulnerabilities in your own work? Or are you already using PASETO somewhere? I'd genuinely like to hear what's blocking adoption on your team.

Source: This post was inspired by "Filling the PASETO gap in JavaScript: paseto-kit (v3/v4 + full PASERK)" by Dev.to. Read the original article