Future-Proofing JWT Security: Crypto-Agility, Post-Quantum Signatures, and IAM Migration

Today, applications are built around identity systems. All API gateways, microservices, mobile backends, and single sign-on flows require some form of authentication and authorization. That trust is often conveyed via a JSON Web Token (JWT) in many systems.

Their compactness, portability, and ability to be easily verified within distributed systems make them popular. A service can accept a token, validate its signature, verify the claims of the token (expiration, audience, subject, and issuer), and determine if the request should be accepted.

But classical public-key cryptography (especially RSA and elliptic-curve signatures) is still widely used in most JWT deployments these days. Some popular algorithms used in OAuth 2.0, OpenID Connect, API gateways, and identity platforms include RS256 and ES256. These algorithms are effective at this time, but are not likely to be secure with the arrival of strong enough quantum computers (Shor, 1994).

The problem isn't with JWTs per se. The problem is that there are lots of ways of signing JWTs that rely on cryptographic problems that may be solved by quantum algorithms in the future. The real problem for developers and platform engineers is how to safely design JWT and IAM systems that will work well when post-quantum signatures become required.

JWT Signing Today

A JWT is usually signed and not encrypted. This distinction matters. While signed JWTs can ensure integrity and authenticity, their payload is typically at risk of being read by anyone who possesses the JWT. The signature assures that the claims were signed by a trusted party and that they have not been altered.

In the example above, an RS256 token that is used in Node.js can be signed in such a way:

const jwt = require("jsonwebtoken");
const fs = require("fs");

const privateKey = fs.readFileSync("private.key");

const token = jwt.sign(
  {
    sub: "user123",
    role: "admin",
    iss: "https://auth.example.com",
    aud: "api://orders-service"
  },
  privateKey,
  {
    algorithm: "RS256",
    expiresIn: "1h",
    keyid: "rsa-key-2026"
  }
);

The receiving service verifies the token using the issuer’s public key:

const publicKey = fs.readFileSync("public.key");

const claims = jwt.verify(token, publicKey, {
  algorithms: ["RS256"],
  issuer: "https://auth.example.com",
  audience: "api://orders-service"
});

This model is particularly helpful as the private key remains with the identity provider and many services are able to verify the tokens with the public key. Hence, the use of RS256 and ES256 in federated identity systems.

The problem that might arise in the future is that RSA and elliptic-curve signatures can be attacked by large-scale quantum computers. If the attacker is able to determine the private key from the public key, then he can create valid-looking tokens and pretend to be a trusted issuer.

Why HS256 Is Not a Universal Replacement

A few teams propose HS256 or HS384 to address quantum risk. These algorithms are based on HMAC-SHA256 or HMAC-SHA384. They are symmetric, not public-key, message authentication codes.

That implies both the signature and verification of the token use the same secret. This can be okay if there is one trusted entity controlling the issuer and the verifier, as in an internal system. But it's not a true replacement for RS256 or ES256 for federated IAM.

However, unlike RS512, with RS256, a number of services can verify tokens with a public key, while the identity provider is the only party that can sign the tokens. In HS256, all the verifiers must use the shared secret. If a verifier is compromised, then the attacker can possibly generate new tokens.

As such, JWTs with HMAC can be helpful to some limited trust boundaries, but should not be considered the primary solution for large IAM platforms, partner integrations, or multi-tenant SaaS apps.

Post-Quantum JWT Direction

Post-quantum migration is expected to concentrate on new digital signature algorithms, not just changing all systems to HMAC. NIST has completed the specification of the post-quantum digital signature standard, ML-DSA, and begun work on the JOSE/COSE specification for representing ML-DSA in the JWT and JWS ecosystems.

To developers, this means that library support, identity-provider support, API gateway support, and key-management updates are of importance when considering the adoption of post-quantum JWTs. It will NOT be a one-line change to the algorithm.

The first step of a realistic migration should start with crypto-agility. Don't permanently hardcode an algorithm. Rather, they should make sure to check tokens by applying hardcoded allowlists for issuer and application context.

Example:

const allowedAlgorithms = {
   "https://auth.example.com": ["RS256", "ES256"],
   "https://internal-auth.example.com": ["HS256"]
};

function getAllowedAlgorithms(issuer) {
  if (!allowedAlgorithms[issuer]) {
    throw new Error("Unknown issuer");
  }
  return allowedAlgorithms[issuer];
}

This is not enough by itself to make the system post-quantum, but it paves the way to controlled migration. The verification layer of the stack can be updated via policy and configuration, not service by service as the approved post-quantum JOSE algorithms are introduced to the stack (NIST, 2021).

Developer Migration Checklist

Inventory the use of JWT in the system. Determine which services issue tokens, which ones verify them, on which algorithms they are based, how keys are rotated, and where JWKS endpoints are located.

Second, “cleanse out risky verification conduct. Do not trust the algorithm of the JWT header without consulting a trusted allowlist. Avoid unrecognized issuers, audiences, expired tokens, and unsuspecting algorithms.

Third, enhance rotation of keys. A short token lifetime minimizes the risk of replay, but does not prevent signing-key compromise. Apply kid values, JWKS rotation, and overlapping key validity windows.

Fourth, don't include sensitive data in signed-only JWTs. Use proper encryption, or store sensitive data on the server if needed to maintain confidentiality.

Fifth, limitations of test infrastructure. The post-quantum signatures can be larger than an RSA or ECDSA signature. These larger tokens can have an impact on HTTP header limits, cookies, proxies, API gateways, logs, and service meshes.

Lastly, centralize JWT validation, if possible. It's easier to migrate a shared middleware, gateway plugin, or security library than any number of dozens of services with custom validation logic.

Conclusion

JWTs will remain important in identity and access management, but the algorithms behind them must evolve. RSA and ECDSA work well now, but don't work in the long run.

Don't panic, don't switch to HS256. While they can be used in some internal systems, JWTs are not a standard solution for public-key federation.

The more fruitful approach is crypto-agility: be aware of the use of JWTs, maintain strict lists of algorithms, rotate keys appropriately, separate authentication and business logic, and get ready for the digital post-quantum signatures (e.g., ML-DSA) as they become available on the library and platform.

With an IAM system that is algorithm-agile, teams that are preparing for it today will be more ready for the transition to post-quantum tomorrow.