01
Zeiteinheit prüfen
exp, nbf und iat verwenden NumericDate in Unix-Sekunden. Millisekunden dürfen nicht unverändert übernommen werden.
Entwicklerreferenz
JWT Claims und OAuth-Fehler
Claim oder OAuth-Fehlercode suchen und Antwortort, fiktives Beispiel sowie RFC-Quelle vergleichen.
JWT Claims
Treffer
exp
Antwortkontext: JWT Claim · RFC 7519
Bedeutung: Ablaufzeit als NumericDate in Unix-Sekunden.
Unix-Sekunden statt Millisekunden vergleichen.
Fiktives Antwortbeispiel
{ "exp": 1893456000 }Nur fiktive Daten, keine echten Zugangsdaten.
Die Suche bleibt im Browser; nur ein Quellenlink öffnet eine externe Seite.
Kategorie
1 von 23 Einträgen
RFC 7519 / 6749 / 6750Geprüft am 23.09.2026
JWT Claims wie exp und aud beschreiben Teile eines Tokens, aber kein bestandener Signaturtest folgt daraus. Hier lassen sich die registrierten Felder ohne Eingabe eines echten Tokens nachschlagen.
Ein OAuth-Fehler gehört zu einer konkreten Antwort: Weiterleitung, JSON des Tokenendpunkts oder Bearer-Challenge. Die Beispiele zeigen diesen Unterschied. Bei Plattformen heißen dieselben Felder auch JWT Ansprüche; deren eigene Regeln gelten zusätzlich.
Warum diese JWT Claims nachschlagen
Warum diese JWT Claims nachschlagen
Bedeutung statt Scheinprüfung
JWT Claims werden mit fiktivem Wert und RFC-Quelle gezeigt. exp verwendet Unix-Sekunden; ein lesbares Payload ist noch kein gültiges Token.
Fehler im richtigen Endpunkt
invalid_request kann in einer Weiterleitung, einer JSON-Antwort oder einem WWW-Authenticate-Header stehen. Die Form entscheidet, wo gesucht werden muss.
Vom Feld zum Kontext
02
Antwortort prüfen
Bei OAuth Fehlercodes zuerst zwischen Autorisierung, Tokenendpunkt und Ressource unterscheiden.
03
Normtext öffnen
Den verlinkten RFC-Abschnitt und die Dokumentation des Anbieters prüfen; echte Tokens im separaten Debugger untersuchen.
Felder, Codes und Quellen
Sieben registrierte Felder
Die sieben JWT Claims aus RFC 7519 haben je ein fiktives Beispiel und einen direkten Definitionslink.
Fehler nach Endpunkt
RFC 6749 unterscheidet Autorisierungs- und Tokenfehler auch bei gleichem Fehlernamen.
Bearer-Kontext
RFC 6750 liefert WWW-Authenticate-Beispiele und empfohlene HTTP-Statuscodes.
Grenzen dieser Nachschlagehilfe
- Keine Echtheitsprüfung
- Diese JWT Claims Referenz nimmt keine Tokens an und entscheidet weder über Signatur noch Sitzung.
- Begrenzter Normbestand
- Abgedeckt sind RFC 7519, 6749 und 6750; OIDC und Anbietererweiterungen werden nicht automatisch ergänzt.
- Beschreibung ist kein Code
- error_description ist optionaler Text für Entwickler. Auf error und Endpunkt reagieren, nicht auf die Formulierung.
- Keine Zugangsdaten eingeben
- Echte JWTs, Signaturschlüssel oder Autorisierungscodes gehören nicht in diese Suche oder URL-Parameter. Die Seite durchsucht nur feste Daten.
- Keine Serveranfrage
- Die Suche kontaktiert keinen Identitätsanbieter und überträgt nichts automatisch an verlinkte Werkzeuge. Echte Anfragen separat prüfen.
- Fehlerkontext bewahren
- invalid_request hat je nach Endpunkt einen anderen Antwortort; invalid_token und insufficient_scope verlangen ebenfalls unterschiedliche Bearer-Behandlung.
- Kein Live-Ablaufstatus
- NumericDate-Beispiele verwenden Unix-Sekunden. Ein fester Beispielwert sagt nichts über eine reale Sitzung oder ein unbekanntes Token aus.
Fragen zu JWT Claims
Was bedeuten iss und aud in einem JWT?
iss nennt den Aussteller; aud nennt den vorgesehenen Empfänger. Der Dienst muss beide Werte passend prüfen.
Ist exp in jedem JWT erforderlich?
Nicht generell. RFC 7519 registriert exp, doch Pflichtfelder bestimmt das jeweilige Profil.
Worin unterscheiden sich invalid_grant und invalid_client?
invalid_client betrifft die Clientauthentifizierung; invalid_grant betrifft Grant oder Refresh-Token.
Darf eine Anwendung error_description auswerten?
Nein. Der optionale Text ist für Menschen und kann sich je nach Anbieter ändern.
Beweist das Dekodieren eines JWT seine Gültigkeit?
Nein. Nach dem Dekodieren sind Signatur, Aussteller, Zielgruppe, Zeit und Richtlinie zu prüfen.
Fehlt ein Eintrag oder ist etwas falsch?
JWT Claims jetzt nachschlagen
Mit exp oder einem OAuth-Fehler beginnen, Endpunkt und RFC-Quelle prüfen und erst danach echte Anmeldedaten bearbeiten.