API Security & JWT with PQC

JWT/JWS/JWE with post-quantum algorithms — ML-DSA signing, ML-KEM key agreement, and OAuth 2.0 migration.

JWT/JWS/JWE Fundamentals

are the foundation of modern API authentication. A JWT is a compact, URL-safe means of representing claims between two parties. The token format is defined in RFC 7519, with signing (, RFC 7515) and encryption (, RFC 7516) as separate specifications.

JWT Compact Serialization (JWS)

BASE64URL(Header).BASE64URL(Payload).BASE64URL(Signature)

The header specifies the algorithm (alg) and token type (typ). The payload carries claims. The signature covers both header and payload.

Header

header with alg (signing algorithm) and typ (token type). Base64url-encoded JSON.

Payload

Claims: sub, iss, exp, aud, plus custom claims. Base64url-encoded JSON.

Signature

Cryptographic signature over header.payload using the algorithm specified in the header. This is where PQC changes everything.

Current JWT Algorithms & Quantum Vulnerability

Every JWT signing algorithm in production today — (RSA-PKCS1-v1_5), (ECDSA P-256), and (Ed25519) — relies on mathematical problems that solves efficiently on a quantum computer. Key agreement algorithms like ECDH-ES are equally vulnerable.

Algorithm	JOSE ID	Type	Quantum Attack	Status
RS256 (RSA-2048)	RS256	Signing	Shor's algorithm	Quantum Vulnerable
ES256 (ECDSA P-256)	ES256	Signing	Shor's algorithm	Quantum Vulnerable
EdDSA (Ed25519)	EdDSA	Signing	Shor's algorithm	Quantum Vulnerable
ECDH-ES (P-256)	ECDH-ES	Key Agreement	Shor's algorithm	Quantum Vulnerable
ML-DSA-65	ML-DSA-65	Signing	None known	Quantum Safe
ML-KEM-768	ML-KEM-768	Key Agreement	None known	Quantum Safe

Harvest Now, Decrypt Later (HNDL): Attackers can capture signed JWTs today and forge signatures once quantum computers break the signing algorithms. For long-lived tokens (refresh tokens, ID tokens with long expiry), this is an immediate concern.

PQC JWT Signing with ML-DSA

The JOSE working group has published draft-ietf-jose-pqc, which defines new alg values for post-quantum algorithms in JWS and JWE. () replaces ECDSA and RSA for JWT signing.

ML-DSA-44

Level 2

Public key: 1,312 bytes

Signature: 2,420 bytes

Comparable to AES-128 security

ML-DSA-65

NIST Level 3

Public key: 1,952 bytes

Signature: 3,309 bytes

Recommended for general use

ML-DSA-87

NIST Level 5

Public key: 2,592 bytes

Signature: 4,627 bytes

Maximum security, largest size

PQC JWT Key Agreement with ML-KEM

(JSON Web Encryption) protects token payloads with authenticated encryption. () replaces ECDH-ES for key agreement in JWE, using a instead of Diffie-Hellman key exchange.

Classical: ECDH-ES Key Agreement

Sender generates ephemeral EC keypair

↓

ECDH(ephemeral_sk, recipient_pk) → shared secret

↓

Concat KDF → Content Encryption Key (CEK)

ECDH is broken by Shor's algorithm (discrete log on elliptic curves).

PQC: ML-KEM Encapsulation

ML-KEM.Encaps(recipient_pk) → (ct, shared_secret)

↓

(shared_secret) → CEK

↓

AES-GCM-Encrypt(CEK, payload) → ciphertext

ML-KEM is a lattice-based KEM, resistant to quantum attacks.

JOSE Header Changes

Migrating to PQC requires updating the header's alg field. The rest of the JWT structure remains identical — the JOSE framework was designed for algorithm agility.

Classical Header

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "ec-key-2024"
}

PQC Header

{
  "alg": "ML-DSA-65",
  "typ": "JWT",
  "kid": "ml-dsa-key-2025"
}

Field	Classical	PQC	Notes
alg	ES256	ML-DSA-65	Algorithm identifier changes to PQC equivalent
typ	JWT	JWT	Token type remains unchanged
kid	ec-key-2024	ml-dsa-key-2025	Key ID references the PQC key

Token Size Implications

The most significant practical impact of PQC JWTs is token size. ML-DSA-65 signatures are 3,309 bytes vs 64 bytes for ES256 — a 51x increase. This has cascading effects on HTTP headers, cookies, bandwidth, and storage.

ES256 JWT (~300 bytes)~300 B

ML-DSA-65 JWT (~4,700 bytes)~4.7 KB

HTTP Header Limit (default)8 KB

HTTP Header Limits

Many servers default to 8 KB header limits. A single ML-DSA-65 JWT in an Authorization header uses ~60% of that budget. With DPoP, two PQC JWTs could exceed the limit.

Cookie Storage

Browser cookies are limited to ~4 KB per cookie. PQC JWTs cannot fit in a single cookie. Session tokens may need to move from cookies to request bodies.

Bandwidth

Mobile APIs with high request rates will see measurable bandwidth increases. Consider token caching and reference tokens as mitigation strategies.

OAuth 2.0 / OIDC with PQC

OAuth 2.0 and rely heavily on JWTs for access tokens, ID tokens, and proofs. Migrating these ecosystems to PQC requires coordinated changes across authorization servers, resource servers, and client applications.

Access Tokens (JWS)

HIGH PRIORITY

Bearer tokens signed by the authorization server

ML-DSA-65 signatures increase token size from ~800 bytes to ~5 KB. May exceed default HTTP header limits.

ID Tokens (JWS)

HIGH PRIORITY

OpenID Connect identity assertions

Same size increase as access tokens. Frontend libraries must handle larger tokens in cookies/localStorage.

DPoP Proofs (JWS)

MEDIUM PRIORITY

Proof of possession for sender-constrained tokens (RFC 9449)

Each API request includes a DPoP proof JWT. PQC signatures add ~4 KB per request overhead.