"alg" (Algorithm) Header Parameter value not allowed

jose (JavaScript) — JOSEAlgNotAllowed, code ERR_JOSE_ALG_NOT_ALLOWED

Ce que cela signifie

L’en-tête alg du jeton désigne un algorithme qui ne figure pas dans la liste des algorithmes autorisés que vous avez passée à jwtVerify. jose refuse le jeton avant toute opération cryptographique. Ce contrôle est voulu : l’en-tête alg est une entrée contrôlée par l’attaquant, et c’est le vérificateur, et non le jeton, qui doit choisir l’algorithme.

Pourquoi cela se produit

• Liste des algorithmes autorisés désynchronisée de l’émetteur

  fréquente

  L’émetteur est passé de RS256 à ES256 (ou a ajouté une nouvelle clé de signature avec un autre algorithme) alors que le vérificateur impose toujours l’ancienne famille. Chaque nouveau jeton échoue tant que la liste des algorithmes autorisés et les clés ne sont pas mises à jour ensemble, et les échecs commencent à la minute exacte du déploiement côté émetteur : une signature caractéristique, précieuse pour l’analyse des journaux.

• La liste des algorithmes autorisés écrit le nom de l’algorithme autrement

  occasionnelle

  La comparaison est une correspondance exacte, sensible à la casse, avec le nom JOSE : « es256 », « ECDSA », « P-256 » ou « SHA256withECDSA » dans un fichier de configuration ne correspondent jamais à un en-tête qui indique « ES256 ». (Une clé qui ne convient pas à l’en-tête, par exemple une clé P-384 pour un jeton ES256 ou une JWK qui déclare un autre alg, échoue autrement, avec une erreur TypeError qui décrit la clé.)

• Un client malveillant ou mal configuré fait varier alg

  rare

  Les jetons qui arrivent avec un alg « none » ou une valeur HS* inattendue sont exactement ce que ce contrôle est censé bloquer. Si des algorithmes étrangers à votre configuration apparaissent dans les journaux, considérez-les comme une tentative de sondage, et non comme un bug à tolérer.

Comment corriger l’erreur

1. 1.

   Aligner la liste des algorithmes autorisés, la clé et la configuration de l’émetteur

   Examinez l’en-tête, puis mettez les trois en accord. Pendant une migration, acceptez temporairement les deux algorithmes, chacun avec sa propre clé, désignée par son kid dans le JWKS.

   import { decodeProtectedHeader, jwtVerify } from "jose";
   
   console.log(decodeProtectedHeader(token)); // { alg: "ES256", kid: "..." }
   await jwtVerify(token, jwks, { algorithms: ["ES256"] });

2. 2.

   Garder la liste des algorithmes autorisés aussi courte que possible

   Ne « corrigez » pas cette erreur en listant tous les algorithmes. Une seule valeur par type de jeton est l’état final sûr ; la RFC 8725 (JWT Best Current Practices) dit la même chose.

   // good: exactly what your issuer signs with
   { algorithms: ["ES256"] }
   // bad: defeats the protection this error provides
   { algorithms: ["ES256", "RS256", "HS256", "PS256"] }

← Parcourir toute la base de données des erreurs de signature