invalid algorithm

Qué significa

El valor del encabezado alg del token no está en la lista de algoritmos que acepta tu verificador. jsonwebtoken lo comprueba antes de tocar la firma, así que el token puede estar perfectamente firmado, solo que con un esquema que no está entre los permitidos. Este filtro es una medida de seguridad que funciona según lo previsto, no un error de análisis.

Por qué ocurre

• El emisor y el verificador no coinciden tras una migración

  frecuente

  El emisor pasó de RS256 a ES256 (o al revés), pero el verificador sigue fijando el valor antiguo en su lista de algoritmos permitidos. Entonces todos los tokens nuevos fallan mientras los antiguos en caché siguen pasando, lo que hace que el despliegue parezca intermitente.

• Lista de permitidos deducida del tipo de clave equivocado

  frecuente

  Desde la v9, cuando no pasas la opción algorithms, jsonwebtoken deduce la lista de permitidos a partir de la clave: si le das una clave pública RSA, los tokens ES256 dan «invalid algorithm» aunque tu intención fuera permitirlos. Pasar una clave EC permitiendo solo RS256 falla del mismo modo. (Una clave RSA con algorithms: ["ES256"] supera esta comprobación y falla en la siguiente, con «"alg" parameter for "rsa" key type must be one of: RS256, PS256, …».)

• Un token de otro emisor

  ocasional

  Los sistemas multiinquilino a veces reciben tokens emitidos por otro proveedor de identidad con otro esquema de firma. La discrepancia de alg es entonces un síntoma: el problema real es que el token no debería llegar a este verificador en absoluto.

Cómo solucionarlo

1. 1.

   Fijar la lista de permitidos a lo que usa realmente el emisor

   Decodifica el encabezado para ver el alg real y luego configura la lista de permitidos exactamente con ese valor; asegúrate también de que el tipo de clave coincide (clave EC para ES256, clave RSA para RS256).

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

2. 2.

   Desplegar los cambios de algoritmo en dos fases

   Durante una rotación de claves o de algoritmo, los verificadores deben aceptar brevemente ambos esquemas, cada uno ligado a su propia clave mediante kid, y después volver a uno solo.

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

← Explorar toda la base de datos de errores de firma