invalid algorithm

Ce que cela signifie

La valeur de l’en-tête alg du jeton ne figure pas dans la liste des algorithmes acceptés par votre vérificateur. jsonwebtoken effectue ce contrôle avant de toucher à la signature : le jeton peut donc être parfaitement signé, simplement avec un schéma que vous n’avez pas autorisé. Ce filtre est un dispositif de sécurité qui fonctionne comme prévu, et non un bogue d’analyse.

Pourquoi cela se produit

• L’émetteur et le vérificateur ne concordent plus après une migration

  fréquente

  L’émetteur est passé de RS256 à ES256 (ou inversement), mais le vérificateur fige toujours l’ancienne valeur dans sa liste d’autorisation d’algorithmes. Chaque nouveau jeton échoue alors que les anciens jetons mis en cache passent encore, si bien que le déploiement semble intermittent.

• Liste d’autorisation déduite du mauvais type de clé

  fréquente

  Depuis la v9, si vous ne passez pas d’option algorithms, jsonwebtoken déduit la liste d’autorisation de la clé : donnez-lui une clé publique RSA, et les jetons ES256 sont rejetés avec « invalid algorithm » même si vous vouliez les autoriser. Passer une clé EC en n’autorisant que RS256 échoue de la même manière. (Une clé RSA avec algorithms: ["ES256"] franchit ce contrôle et échoue au suivant, avec « "alg" parameter for "rsa" key type must be one of: RS256, PS256, … ».)

• Un jeton d’un autre émetteur

  occasionnelle

  Les systèmes multilocataires reçoivent parfois des jetons émis par un autre fournisseur d’identité, avec un autre schéma de signature. Le désaccord sur alg n’est alors qu’un symptôme : le vrai problème est que ce jeton ne devrait pas du tout parvenir à ce vérificateur.

Comment corriger l’erreur

1. 1.

   Aligner la liste d’autorisation sur ce que l’émetteur utilise réellement

   Décodez l’en-tête pour voir l’alg réel, puis réglez la liste d’autorisation exactement sur cette valeur, en vous assurant que le type de clé correspond (clé EC pour ES256, clé RSA pour RS256).

   const { header } = jwt.decode(token, { complete: true });
   console.log(header.alg); // e.g. "ES256"
   
   jwt.verify(token, ecPublicKeyPem, { algorithms: ["ES256"] });

2. 2.

   Déployer les changements d’algorithme en deux phases

   Pendant une rotation de clé ou d’algorithme, les vérificateurs doivent brièvement accepter les deux schémas, chacun lié à sa propre clé via kid, puis revenir à un seul.

   // transition window only:
   jwt.verify(token, keyForKid(header.kid), { algorithms: ["ES256", "RS256"] });
   // after all RS256 tokens expired:
   jwt.verify(token, ecPublicKeyPem, { algorithms: ["ES256"] });

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