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.
Von Mateusz Viola
Betreiber & redaktionelle Verantwortung jwtdecoder.de
Veröffentlicht
Aktualisiert:
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:
- Token-Format prüfen (drei Punkt-getrennte base64url-Teile)
- Header parsen, alg gegen Whitelist prüfen
- Signatur verifizieren (mit Secret oder Public Key)
- Erst dann Payload parsen und Claims prüfen: iss, aud, exp, nbf
- 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.