"alg" (Algorithm) Header Parameter value not allowed

jose (JavaScript) — JOSEAlgNotAllowed, code ERR_JOSE_ALG_NOT_ALLOWED

Qué significa

El encabezado alg del token indica un algoritmo que no está en la lista de algoritmos permitidos que pasas a jwtVerify. jose lo rechaza antes de ejecutar ninguna operación criptográfica. Este control es deliberado: el encabezado alg es una entrada que controla el atacante, y es el verificador —no el token— quien debe elegir el algoritmo.

Por qué ocurre

• Lista de permitidos desincronizada con el emisor

  frecuente

  El emisor pasó de RS256 a ES256 (o añadió una nueva clave de firma con otro algoritmo) mientras el verificador sigue fijado a la familia anterior. Todos los tokens nuevos fallan hasta que se actualizan a la vez la lista de permitidos y las claves, y los fallos empiezan en el minuto exacto del despliegue del emisor: una pista útil para el análisis forense de los registros.

• La lista de permitidos escribe el algoritmo de otra forma

  ocasional

  La comparación es una coincidencia exacta, que distingue mayúsculas de minúsculas, con el nombre JOSE: «es256», «ECDSA», «P-256» o «SHA256withECDSA» en un archivo de configuración nunca coinciden con un encabezado que dice «ES256». (Una clave que no encaja con el encabezado —una clave P-384 para un token ES256, una JWK cuyo propio alg es distinto— falla de otra manera, con un TypeError que describe la clave).

• Un cliente hostil o mal configurado cambia el alg

  rara

  Los tokens que llegan con alg: "none" o con un valor HS* inesperado son precisamente lo que esta comprobación debe impedir. Si ves algoritmos ajenos en los registros, trátalo como un sondeo, no como un fallo que haya que tolerar.

Cómo solucionarlo

1. 1.

   Alinear la lista de permitidos, la clave y la configuración del emisor

   Mira el encabezado y luego haz que las tres coincidan. Durante las migraciones, acepta ambos algoritmos temporalmente, cada uno con su propia clave, identificada por el kid del JWKS.

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

2. 2.

   Mantener la lista de permitidos lo más corta posible

   No «arregles» este error añadiendo todos los algoritmos a la lista. Un valor por tipo de token es el estado final seguro; el RFC 8725 (buenas prácticas actuales para JWT) dice lo mismo.

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

← Explorar toda la base de datos de errores de firma