jwtdecoder.de

Ratgeber · JWT 2026

JWT Standard-Claims nach RFC 7519

Was die sieben "Registered Claim Names" bedeuten, warum aud-Validierung kritisch ist und wie man Clock-Skew bei exp/nbf handhabt.

Foto von Mateusz Viola

Von Mateusz Viola

Betreiber & redaktionelle Verantwortung jwtdecoder.de

Sieben Standard-Claims

RFC 7519 §4.1 definiert sieben "Registered Claim Names". Sie sind alle optional - aber wenn vorhanden, müssen sie der spezifizierten Semantik folgen. In Production-Tokens sind iss, sub, exp und iat fast immer gesetzt; aud, nbf, jti je nach Use-Case.

iss - Issuer

Identifiziert die ausstellende Instanz. Typisch ein URL-String wie "https://auth.example.com". Der Verifier MUSS prüfen, ob iss einen erwarteten Wert hat - sonst akzeptiert er Tokens beliebiger fremder Issuer.

// Verifier-Pseudo-Code
if (token.iss !== "https://auth.example.com") {
  throw new Error("Untrusted issuer");
}

In OIDC ist iss die Base-URL des Auth-Providers, von der auch /.well-known/openid-configuration und /.well-known/jwks.json abgeleitet werden können.

sub - Subject

Der Identifier des Subjects (typisch der User). Muss innerhalb des Issuer-Scopes eindeutig sein. Konvention: stabile, nicht-änderbare ID - eine UUID oder die Datenbank-Primary-Key. Niemals die Email-Adresse, weil Email-Adressen sich ändern können.

Application-Code sollte sub als Primary-Identifier benutzen und User-Datensätze damit verknüpfen. Wenn ein User seine Email ändert, bleibt sub stabil - und damit auch die User-Identität im System.

aud - Audience

Die Empfänger, für die das Token bestimmt ist. Wert kann String oder Array sein. Der Verifier MUSS prüfen, ob sein eigener Service-Identifier im aud-Claim steht - sonst kann ein Token, das für Service A ausgestellt wurde, gegen Service B "wiederverwendet" werden.

// API-Server (myapi.example.com) prüft:
const audValid = Array.isArray(token.aud)
  ? token.aud.includes("myapi.example.com")
  : token.aud === "myapi.example.com";
if (!audValid) throw new Error("Wrong audience");

Diese Prüfung ist eine der häufigsten Auslassungen in produktivem Code - und ein typischer Pentest-Befund.

exp - Expiration Time

Unix-Timestamp (Sekunden seit Epoch), bis zu dem das Token gültig ist. Pflicht-Prüfung für jeden Verifier. Vorsicht: NumericDate ist Sekunden, nicht Millisekunden - bei Verwechslung sind Tokens entweder fast sofort abgelaufen (Millisekunden zu Sekunden) oder gefährlich lange gültig (Sekunden zu Millisekunden).

Clock-Skew-Toleranz: Server-Uhren laufen nie exakt synchron. Übliche Praxis: ±60 Sekunden Toleranz. Beispiel:

const now = Math.floor(Date.now() / 1000);
const skewSeconds = 60;
if (token.exp + skewSeconds < now) throw new Error("Expired");

iat - Issued At

Wann das Token ausgestellt wurde. Allein erzwingt iat keine Gültigkeit. Use-Cases: Token-Reuse-Detection im Refresh-Pattern (jüngeres Token erkennt älteres als kompromittiert), Audit-Logs, "Time-Since-Issued"-basierte Policy-Checks.

nbf - Not Before

Spiegel-Bild zu exp: Token wird erst ab nbf gültig. Use-Case: Tokens mit zukünftiger Gültigkeit, z.B. ein Einladungs-Token, das erst ab einer bestimmten Uhrzeit funktionieren soll. Selten verwendet - die meisten Tokens sind ab iat gültig.

if (token.nbf && token.nbf > now + skewSeconds) {
  throw new Error("Token not yet valid");
}

jti - JWT ID

Eindeutige ID des Tokens, innerhalb des Issuer-Scopes. Use-Cases:

  • Replay-Schutz: Server merkt sich verwendete jtis bis zu deren exp und lehnt Wiederverwendung ab.
  • Manuelles Revoke: einzelnen Token in Blacklist setzen.
  • Audit: jeden Token-Use mit jti loggen, später nachvollziehen.

Bei hohem Volume Lookup-Kosten beachten - meist Redis oder Bloom-Filter, nicht Hauptdatenbank.

Validierungs-Reihenfolge

Best-Practice-Reihenfolge im Verifier:

  1. Token-Format prüfen (drei Punkt-getrennte base64url-Teile)
  2. Header parsen, alg gegen Whitelist prüfen
  3. Signatur verifizieren (mit Secret oder Public Key)
  4. Erst dann Payload parsen und Claims prüfen: iss, aud, exp, nbf
  5. Optional: jti gegen Replay-Liste, custom Claims

Häufiger Fehler: Claims werden vor der Signaturprüfung gelesen. Wenn dann ein early-return ohne Signaturcheck passiert, wird unsigniertes Token akzeptiert.

Im JWT Decoder werden alle Standard-Claims automatisch erkannt und mit Beschreibungen versehen. Zeitstempel (exp, iat, nbf) werden human-readable formatiert plus die "noch X Minuten gültig"-Anzeige.

Mehr zum Thema