missing required "aud" claim

Der Name des Claims hängt davon ab, welcher Claim fehlt (`"aud"`, `"iss"`, `"exp"`, `"sub"`, `"iat"`…). `err.claim` enthält den Namen, und `err.reason` ist `"missing"`.

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

Was der Fehler bedeutet

Dem Token fehlt ein Claim, den deine Prüfoptionen zur Pflicht machen. jose behandelt einen Claim nicht nur dann als erforderlich, wenn du ihn in `requiredClaims` aufführst, sondern auch immer dann, wenn du es anweist, diesen Claim zu prüfen: `audience` verlangt `aud`, `issuer` verlangt `iss`, `subject` verlangt `sub` und `maxTokenAge` verlangt `iat`. Der Name des Claims in Anführungszeichen zeigt dir, welcher fehlt; die Signatur war bereits gültig.

Warum der Fehler auftritt

• Eine Prüfoption setzt den Claim voraus

  häufig

  Mit `audience: "https://api.example.com"` sagst du: „Das Token muss für diese API bestimmt sein“ – ein Token ohne `aud` kann das nicht erfüllen, deshalb meldet jose den Claim als fehlend, statt die Prüfung stillschweigend bestehen zu lassen. Dasselbe gilt für `issuer`, `subject` und `maxTokenAge`.

• Der Aussteller schreibt diesen Claim nie

  häufig

  Selbst gebaute oder interne Token-Dienste lassen `aud` oder `exp` oft weg. Tokens ohne `exp` laufen nie ab; Tokens ohne `aud` lassen sich bei jedem Dienst, der demselben Aussteller vertraut, erneut einsetzen (Replay) – es lohnt sich, beides an der Quelle zu beheben.

• Der Claim steht in requiredClaims

  gelegentlich

  `requiredClaims: ["exp", "jti"]` macht diese Claims unabhängig von ihren Werten zur Pflicht. Ein Token-Typ, dem einer davon berechtigterweise fehlt (zum Beispiel ein langlebiges Service-Token ohne `exp`), scheitert hier, und das ist so gewollt.

• Eine andere Art von Token hat die prüfende Seite erreicht

  gelegentlich

  Refresh Tokens, Logout-Tokens oder providerspezifische Tokens sind ebenfalls JWTs, tragen aber andere Claim-Sets. Wirkt das Claim-Set unbekannt, wurde das falsche Token gesendet.

So behebst du den Fehler

1. 1.

   Fehlenden Claim und vorhandene Claims protokollieren

   Das Fehlerobjekt stellt `claim`, `reason` und die dekodierte `payload` bereit. Protokollierst du sie, unterscheidest du mit einer einzigen Anfrage „der Aussteller schreibt ihn nicht“ von „das falsche Token wurde gesendet“.

   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.

   Claim vom Aussteller aufnehmen lassen

   Korrigiere lieber das Token, statt die Prüfung zu lockern. Erst `aud`, `iss` und `exp` machen es sicher, ein JWT zu akzeptieren; RFC 8725 empfiehlt, dass jedes Token sie enthält.

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

← Gesamte Signaturfehler-Datenbank durchsuchen