How does RS256-to-HS256 algorithm confusion let an attacker forge a valid JWT?

## The setup JWT signature algorithms fall into two families with fundamentally different key models. Symmetric algorithms such as HS256 use one shared secret for both producing and checking the MAC — anyone who can verify can also forge. Asymmetric algorithms such as RS256 use a private key to sign and a public key to verify — the verifier holds material that is deliberately published and cannot mint tokens with it. Algorithm confusion collapses that distinction by making the verifier use asymmetric key material in a symmetric routine. ## The attack, step by step 1. The system issues RS256 tokens. Verifiers hold the issuer's RSA public key, which is public by design — served from the issuer's key set, often retrievable in a single request. 2. The attacker takes a token, edits the payload to elevate privileges, and rewrites the header to `{"alg":"HS256","kid":"..."}`. 3. The attacker computes `HMAC-SHA256(key = exact bytes of the issuer's public key, message = base64url(header) + "." + base64url(payload))` and uses that as the signature. 4. The vulnerable verifier reads `alg` as HS256, fetches "the key for this issuer" — the RSA public key it has cached — and passes those bytes to the HMAC verification routine. 5. Both sides computed the same MAC with the same key over the same bytes, so verification succeeds. The attacker never touched the private key. The only secret required was something published on purpose. ## The exact byte representation matters to the attacker In practice the attacker must match the byte encoding of the public key that the verifier passes in — a PEM-encoded SPKI block including headers and newlines, a DER blob, or a modulus reconstructed from the key set's `n` and `e` values. That is a small amount of trial and error over a handful of common encodings, not a barrier. Treat the requirement as a formality rather than a mitigation. ## Root cause The vulnerability is not in RSA and not in HMAC. It is an API and configuration flaw: **the verifier let the token select the algorithm while holding a single untyped blob of key material**. Two design errors compound: - The algorithm is read from attacker-controlled input rather than from configuration. - The key is a byte string with no attached notion of "this is an RSA public key, usable only for RSA verification". Either error alone is survivable; together they are a full authentication bypass. ## Defences, strongest first **1. Pin the algorithm at the verifier.** State "this issuer signs RS256" in configuration and reject any token whose `alg` differs, before key lookup. This alone closes the attack. **2. Bind keys to algorithms.** A key set entry carries `kty` (key type), and may carry `alg` and `use`. Select only keys whose type and declared algorithm match the operation you are performing, so an RSA entry can never satisfy a MAC verification. Libraries that model keys as typed objects rather than byte arrays make the mistake unrepresentable — passing an RSA public key where an HMAC secret is required simply will not compile or will throw. **3. Do not mix families for one issuer.** A verifier that accepts both HS256 and RS256 from the same issuer has to be exactly right about which key goes with which algorithm on every path. Do not accept an algorithm set spanning families. **4. Separate key material by purpose.** Never store an HMAC secret and a public key in the same configuration slot, and never let one lookup function return either. ## Detection and testing Write a negative test that performs the attack: take a legitimate RS256 token, rewrite the header to HS256, edit a claim, and sign with the issuer's public key bytes in the encodings you actually publish. Assert an authentication failure. This test is worth keeping permanently — it protects against a library upgrade that loosens defaults or a configuration change that widens the accepted algorithm list. Operationally, alert on any token arriving with an unexpected `alg` for a known issuer. Legitimate clients never produce one, so a non-zero rate means either a misconfigured service or someone probing. ## The wider family The same shape appears in other substitutions — an unsecured token with an empty signature, or a header field that redirects key lookup to a source the attacker controls. All of them are instances of one rule: **the credential must never influence how the credential is checked**. Algorithm, key, and key source are the verifier's decisions, derived from configuration. A candidate who states that rule and then derives the specific attacks from it is demonstrating the understanding the question is testing.