Why I built a post-quantum signing API (and why JWT is on borrowed time)

#webdev #api #opensource #security

JWT with RS256/ES256 is everywhere. It's also going to be broken.

Not today. But the clock is ticking — and the timeline is shorter than most developers think.

The problem with classical signatures

Every JWT signed with RS256 or ES256 relies on RSA or ECDSA. These algorithms are vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer. NIST finalized the post-quantum replacements in August 2024 — but most developers haven't started migrating yet.

The threat isn't just future decryption. Nation-state actors are already harvesting signed traffic today to decrypt and forge once quantum computers arrive. "Harvest now, decrypt later" is a real attack pattern.

What I built

I built FIPSign — a signing API built on ML-DSA-65 (NIST FIPS 204). The idea is simple: you call /sign with any payload, get back a quantum-resistant token. No infrastructure to manage, no keys to generate or rotate, no DevOps.

const { token } = await pq.sign({
  sub: 'user_123',
  role: 'admin',
  expiresInSeconds: 3600,
})

const { valid, payload } = await pq.verify(token)

Not just for auth

Most post-quantum signing tools focus only on user authentication. FIPSign lets you sign anything — the only required field is sub, any string identifying the entity:

sub: "user_123" — user sessions
sub: "order_456" — payment intents
sub: "doc_789" — document certification
sub: "device_iot_001" — IoT firmware

How revocation works

Revocation is built in. When you revoke a token, we store a SHA-256 hash of the ML-DSA-65 signature as a blacklist entry in Cloudflare D1. Every remote /verify call checks that blacklist. Entries expire automatically when the original token would have expired.

Local verification (localVerify: true) runs entirely in memory at ~1ms with no API call — but doesn't check revocation. Use remote verification for payments and admin actions.

The pricing model

No monthly subscriptions. 10,000 free tokens/month that reset automatically. Each sign, verify, or revoke costs 1 token. For most projects, 10,000 tokens/month is enough to never pay anything. If you need more, token packs never expire and accumulate across purchases.

Why ML-DSA-65 specifically?

ML-DSA-65 is NIST security level 3 — the right balance between security and signature size for API use cases. ML-DSA-44 is faster but lower security. ML-DSA-87 produces larger signatures with no practical benefit for most applications.

The implementation uses @noble/post-quantum — a widely audited library you can verify independently.

Try it

npm install fipsign-sdk

Full guide at fipsign.dev/guide. Free account at app.fipsign.dev — no credit card.

Happy to answer any questions about the cryptography, the architecture, or the migration path from JWT.

DEV Community