missing required "aud" claim

El nombre del claim cambia según el claim que falte (`"aud"`, `"iss"`, `"exp"`, `"sub"`, `"iat"`…). `err.claim` contiene el nombre y `err.reason` vale `"missing"`.

jose (JavaScript) — JWTClaimValidationFailed, code ERR_JWT_CLAIM_VALIDATION_FAILED, reason "missing"

Qué significa

El token no contiene un claim (declaración) que tus opciones de verificación hacen obligatorio. jose considera obligatorio un claim no solo cuando lo incluyes en `requiredClaims`, sino también siempre que le pides que lo compruebe: `audience` exige `aud`, `issuer` exige `iss`, `subject` exige `sub` y `maxTokenAge` exige `iat`. El nombre del claim entre comillas indica cuál falta; la firma ya era válida.

Por qué ocurre

• Una opción de verificación implica el claim

  frecuente

  Definir `audience: "https://api.example.com"` significa «el token tiene que ser para esta API»: un token sin `aud` no puede cumplirlo, así que jose informa de que falta el claim en lugar de darlo por bueno en silencio. Lo mismo vale para `issuer`, `subject` y `maxTokenAge`.

• El emisor nunca escribe ese claim

  frecuente

  Los servicios de tokens caseros o internos suelen omitir `aud` o `exp`. Los tokens sin `exp` nunca caducan; los tokens sin `aud` se pueden reenviar a cualquier servicio que confíe en el mismo emisor: merece la pena corregir ambas cosas en el origen.

• El claim figura en requiredClaims

  ocasional

  `requiredClaims: ["exp", "jti"]` hace obligatorios esos claims sea cual sea su valor. Un tipo de token al que legítimamente le falta uno de ellos (por ejemplo, un token de servicio de larga duración sin `exp`) falla aquí por diseño.

• Al verificador llegó otro tipo de token

  ocasional

  Los tokens de actualización, los tokens de cierre de sesión o los tokens propios de un proveedor también son JWT, pero llevan otros conjuntos de claims. Si el conjunto de claims no te resulta familiar, se envió el token equivocado.

Cómo solucionarlo

1. 1.

   Registrar el claim que falta y los claims presentes

   El objeto de error expone `claim`, `reason` y el `payload` decodificado. Registrarlos permite distinguir «el emisor no lo escribe» de «se envió el token equivocado» con una sola solicitud.

   import { errors, jwtVerify } from "jose";
   
   try {
     await jwtVerify(token, jwks, { algorithms: ["ES256"], audience: "https://api.example.com" });
   } catch (err) {
     if (err instanceof errors.JWTClaimValidationFailed && err.reason === "missing") {
       console.error("token lacks claim:", err.claim, "claims present:", Object.keys(err.payload));
     }
     throw err;
   }

2. 2.

   Hacer que el emisor incluya el claim

   Mejor corregir el token que relajar el verificador. `aud`, `iss` y `exp` son lo que hace seguro aceptar un JWT; el RFC 8725 recomienda que todos los tokens los lleven.

   import { SignJWT } from "jose";
   
   const token = await new SignJWT({ scope: "orders:read" })
     .setProtectedHeader({ alg: "ES256", kid })
     .setIssuer("https://issuer.example.com")
     .setAudience("https://api.example.com")   // the claim the verifier requires
     .setIssuedAt()
     .setExpirationTime("10m")
     .sign(privateKey);

← Explorar toda la base de datos de errores de firma