missing required "aud" claim

O nome da claim muda conforme a claim ausente (`"aud"`, `"iss"`, `"exp"`, `"sub"`, `"iat"`…). `err.claim` contém o nome, e `err.reason` é `"missing"`.

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

O que significa

O token não contém uma claim que suas opções de verificação tornam obrigatória. O jose trata uma claim como obrigatória não só quando você a lista em `requiredClaims`, mas também sempre que você pede que ele verifique essa claim: `audience` exige `aud`, `issuer` exige `iss`, `subject` exige `sub` e `maxTokenAge` exige `iat`. O nome da claim entre aspas indica qual delas está ausente; a assinatura já era válida.

Por que acontece

• Uma opção de verificação pressupõe a claim

  comum

  Definir `audience: "https://api.example.com"` significa “o token precisa ser destinado a esta API” — um token sem `aud` não tem como atender a isso, então o jose informa a claim como ausente em vez de aprovar o token silenciosamente. O mesmo vale para `issuer`, `subject` e `maxTokenAge`.

• O emissor nunca inclui essa claim

  comum

  Serviços de token internos ou feitos à mão muitas vezes omitem `aud` ou `exp`. Tokens sem `exp` nunca expiram; tokens sem `aud` podem ser reutilizados em qualquer serviço que confie no mesmo emissor — vale a pena corrigir os dois problemas na origem.

• A claim está listada em requiredClaims

  ocasional

  `requiredClaims: ["exp", "jti"]` torna essas claims obrigatórias independentemente dos valores. Um tipo de token que legitimamente não tem uma delas (por exemplo, um token de serviço de longa duração sem `exp`) falha aqui de propósito.

• Um tipo diferente de token chegou ao verificador

  ocasional

  Tokens de atualização, tokens de logout ou tokens específicos do provedor também são JWTs, mas trazem conjuntos de claims diferentes. Se o conjunto de claims parecer estranho, foi enviado o token errado.

Como corrigir

1. 1.

   Registrar no log a claim ausente e as claims presentes

   O objeto de erro expõe `claim`, `reason` e o `payload` decodificado. Registrá-los no log distingue “o emissor não inclui a claim” de “foi enviado o token errado” com uma única requisição.

   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.

   Fazer o emissor incluir a claim

   Prefira corrigir o token a afrouxar o verificador. `aud`, `iss` e `exp` são o que torna um JWT seguro para aceitar; a RFC 8725 recomenda que todo token traga essas claims.

   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);

← Ver toda a base de erros de assinatura