Glossary
Claim
Eine Schlüssel-Wert-Behauptung innerhalb einer JWT-Nutzlast
By Buğra SözeriPublished Updated
Ein Claim ist ein Name/Wert-Paar in einer JWT-Nutzlast, das etwas über das Subjekt des Tokens behauptet. Claims sind JSON-Eigenschaften; die Nutzlast ist ein JSON-Objekt aus ihnen. In RFC 7519 §4 definierte Standard-Claims:
iss— Issuer (Aussteller): wer das Token erstellt hat.sub— Subject (Subjekt): worauf sich das Token bezieht (typischerweise eine Benutzer-ID).aud— Audience (Zielgruppe): für wen das Token bestimmt ist. Kann ein String oder ein Array sein.exp— Expiry (Ablauf): Unix-Sekunden, nach denen das Token abgelehnt werden muss.iat— Issued At (Ausgestellt am): Unix-Sekunden, zu denen das Token erstellt wurde.nbf— Not Before (Nicht vor): Unix-Sekunden, vor denen das Token ungültig ist.jti— JWT ID: ein eindeutiger Bezeichner zur Verfolgung des Widerrufs.
Über den Standardsatz hinaus fügen Anwendungen ihre eigenen Claims hinzu: role, email, tenant_id, permissions usw. RFC 7519 schränkt nicht ein, wie benutzerdefinierte Claims aussehen, obwohl die IANA ein Register bekannter Namen führt, um Kollisionen zu vermeiden.
Drei unterscheidenswerte Klassen von Claims: registrierte (die sieben oben, IANA-verwaltet), öffentliche (bei der IANA registriert oder unter einem URI namensraumiert, um Konflikte zu vermeiden) und private (zwischen Aussteller und Empfänger einvernehmlich vereinbart; keine Namensraumierung).
Decodieren und inspizieren Sie jeden Claim in einem JWT mit unserem JWT-Decoder. Er stellt die Standard-Claims separat dar und zeigt die Zeit bis zum Ablauf gegenüber der aktuellen Zeit Ihres Rechners.
Namensraumierung benutzerdefinierter Claims — die Standardpraxis: Wenn eine Anwendung benutzerdefinierte Claims hinzufügt, die später in ein zwischen Anbietern geteiltes Token eingebettet werden könnten, stellen Sie ihnen einen URI voran, den Sie besitzen. Auth0 verwendet https://yourdomain.com/claims/role; AWS Cognito verwendet cognito:groups. Bloße Namen wie role oder permissions sind bequem, riskieren aber, mit künftig IANA-registrierten Claims und mit den Konventionen anderer Anbieter zu kollidieren. OpenID Connect legt bestimmte konventionelle Namen fest (email, name, given_name, family_name, picture, locale), die über Identitätsanbieter hinweg stabile Bedeutungen haben — diese können in jedem OIDC-konformen Ablauf unverändert verwendet werden. Referenz: IANA JSON Web Token Claims Registry.
Ein durchgerechnetes Beispiel: exp und nbf validieren
Betrachten Sie eine JWT-Nutzlast {"sub":"42","iat":1716220800,"exp":1716224400,"nbf":1716220800}. Das Token wurde zum Unix-Zeitstempel 1716220800 (20.05.2024 16:00:00 UTC) ausgestellt, ist ab sofort gültig und läuft um 1716224400 (20.05.2024 17:00:00 UTC) ab — eine Lebensdauer von einer Stunde. Ein korrekter Prüfer liest die aktuelle Unix-Zeit, lehnt das Token ab, wenn now ≥ exp (mit optionalem kleinem Spielraum, typischerweise 30–60 Sekunden, um Uhrendrift über Dienste hinweg aufzufangen), und lehnt ab, wenn now < nbf. RFC 7519 §4.1.4 schreibt vor, dass die exp-Verarbeitung Uhrendrift “MUSS” berücksichtigen, überlässt die Toleranz aber dem Implementierer. Ein 60-Sekunden-Spielraum ist der faktische Industriestandard; jose, jsonwebtoken und pyjwt verwenden allesamt konfigurierbare Fenster von 0–60 s.
Warum es zählt: die Sicherheitsimplikationen
Die meisten JWT-Sicherheitsvorfälle gehen auf ausgelassene Claim-Validierungen zurück, nicht auf kryptografische Fehler. Die Auth0-Empfehlung CVE-2018-0114 von 2018 dokumentierte Bibliotheken, die die Signatur verifizierten, aber exp übersprangen, was die unbegrenzte Wiedergabe gestohlener Tokens erlaubte. Mehrere Frameworks wurden mit Standardprüfern ausgeliefert, die aud ignorieren, sodass ein für einen Dienst ausgestelltes Token von einem anderen in derselben Vertrauensdomäne akzeptiert wird. Best Practice: Verifizieren Sie stets den vollständigen Satz der zutreffenden Standard-Claims (iss, aud, exp, nbf, plus Signatur und Algorithmus-Positivliste) — jede Bibliothek macht diese als Konstruktor- oder Verify-Aufruf-Optionen verfügbar, und die Kosten, sie zu aktivieren, sind im Wesentlichen null. Referenz: RFC 8725 — JSON Web Token Best Current Practices.
Rechner ausprobieren
Decodieren Sie ein JWT, um genau zu sehen, welche Claims es trägt — iss, sub, exp und alle benutzerdefinierten.
JWT-Decoder öffnen →Frequently asked questions
- Was ist ein Claim in einem JWT?
- Ein Claim ist ein Schlüssel-Wert-Paar in der JSON-Nutzlast eines JSON Web Token (JWT). Registrierte Claims wie exp (Ablaufzeit), sub (Subjekt) und iss (Aussteller) sind durch RFC 7519 standardisiert; private Claims sind benutzerdefinierte Schlüssel-Wert-Paare, die von den das Token verwendenden Parteien vereinbart werden.
- Wie werden Claims in der Praxis verwendet?
- Ein Authentifizierungsserver stellt ein JWT mit Claims wie {"sub": "user-123", "role": "admin", "exp": 1800000000} aus. Die API liest den role-Claim, um Zugriffsrechte zu bestimmen, ohne die Datenbank erneut abzufragen — der Claim wird vertraut, weil die JWT-Signatur verifiziert, dass er nicht manipuliert wurde.
- Was ist der Unterschied zwischen einem registrierten und einem privaten Claim?
- Registrierte Claims (iss, sub, aud, exp, nbf, iat, jti) sind von der IANA standardisiert und haben definierte Semantik. Private Claims sind benutzerdefinierte Felder, die für Ihre Anwendung spezifisch sind, wie {"tenant_id": "acme-corp"} — für sie gibt es keine standardisierte Bedeutung.
- Sind JWT-Claims verschlüsselt?
- Nein — in einem Standard-JWT (JWS) ist die Nutzlast nur Base64url-codiert, nicht verschlüsselt. Jeder, der das Token besitzt, kann die Claims decodieren und lesen. Verwenden Sie JWE (JSON Web Encryption), wenn Claims vertraulich sein müssen, oder verzichten Sie ganz darauf, sensible Daten in Claims abzulegen.
Related
Published May 16, 2026 · Last reviewed May 31, 2026