JWT Key Confusion

// Heliotrope SSO · token verification
const jwt = require("jsonwebtoken");
const publicKey = fs.readFileSync("./public.pem");  // shipped with the app

function verifyToken(token) {
  // BUG: no explicit algorithm list. The library reads alg from the token header.
  return jwt.verify(token, publicKey);
}

{
  "alg": "RS256",
  "typ": "JWT"
}

{
  "sub": "alice@heliotrope.com",
  "user_id": 1001,
  "role": "employee",
  "iat": 1717592000,
  "exp": 1717595600
}

RSA-SHA256 over
header + "." + payload,
signed with private key.

(opaque to us — we don't
have the private key)

Why this works

JWT libraries take the algorithm from the token header by default and dispatch to the corresponding verify routine. The routine is told which key to use — but the routine doesn't check that the key matches the algorithm. For RSA, the key is expected to be an RSA public key. For HMAC, the key is expected to be a shared secret — just bytes.

An RSA public key is also just bytes. When the HMAC verify routine receives publicKey (the variable that holds the PEM-encoded RSA public key), it treats those bytes as an HMAC secret. The attacker signed their forged token with the same bytes, so the HMAC check passes.

The root cause is the library's "smart" algorithm dispatch — specifically, that the application code does not specify which algorithms it expects. The server intended to use RSA; the library obediently switched to HMAC the moment the token's header asked it to.

The fix

Two fixes, applied together:

• Pin the algorithm in the verify call. Every modern JWT library accepts an explicit algorithm list:

  jwt.verify(token, publicKey, { algorithms: ['RS256'] });

  With this, the library rejects any token whose alg is not in the list — including HS256.
• Use different key material for different algorithms. The RSA key for RS256; a separate, never-published, high-entropy secret for HS256 if you use it elsewhere. Don't share keys across primitives.

Most JWT libraries written in the last few years default to algorithm-pinning. The legacy default of "read alg from header" is responsible for years of CVEs across virtually every language ecosystem.