Si un service vérifie des jetons RS256 avec verify(token, publicKeyPem) et que la bibliothèque accepte aussi HS256 avec n’importe quelle clé fournie, un attaquant prend la clé publique (publiée dans le JWKS), calcule un HMAC sur un en-tête et une charge utile forgés en utilisant ces octets comme secret, et indique "alg": "HS256" ; le serveur vérifie alors un HMAC valide. Tim McLean a décrit cette attaque avec none en 2015, et des variantes continuent d’apparaître dans de nouvelles bibliothèques et de nouveaux frameworks, y compris via des JWK intégrées dans l’en-tête jwk du jeton.
La correction (RFC 8725 §3.1) consiste à lier chaque clé à exactement un algorithme côté vérificateur : listes d’algorithmes autorisés, objets de clé typés qui ne peuvent pas servir de secrets HMAC, alg de chaque JWK comparé à celui du jeton, et jamais de sélection de clés à partir des jwk, jku ou x5u fournis par le jeton sans décision de confiance. Les noms d’algorithmes entièrement spécifiés de la RFC 9864 suppriment l’ambiguïté voisine des identifiants polymorphes comme EdDSA.