Back

JWT-Decoder

JSON Web Tokens (JWTs) sind eine kompakte, URL-sichere Möglichkeit, Claims zwischen zwei Parteien darzustellen. Die meisten JWTs sind mit JWS (JSON Web Signature) signiert, was die Integrität sicherstellt, aber den Inhalt nicht verschlüsselt. Dieses Tool dekodiert Header und Payload, um Claims anzuzeigen, stellt Zeitstempel in menschenlesbarem Format dar und zeigt den Ablaufstatus des Tokens an.

Spezifikationen

Haeufige Anwendungsfaelle

  • OAuth-2.0- und OpenID-Connect-Authentifizierungsflows debuggen
  • Access-Tokens und ID-Tokens von Identity-Providern untersuchen (Auth0, Okta, Keycloak)
  • Token-Claims bei der API-Entwicklung auf erwartete Werte prüfen
  • Token-Ablauf bei der Fehlersuche von "401 Unauthorized"-Fehlern prüfen
  • Token-Struktur beim Integrieren mit Drittanbieter-Diensten verstehen
  • Tokens für Sicherheitsüberprüfung auditieren (Algorithmus, Claims, Ablauf)

Funktionen

  • JWT-Header und -Payload dekodieren (JWS-Format)
  • Algorithmus (HS256, RS256, ES256, PS256, EdDSA) und Token-Typ anzeigen
  • Registrierte Claims parsen: iss (Aussteller), sub (Subjekt), aud (Publikum), exp (Ablauf), nbf (nicht vor), iat (ausgestellt am), jti (JWT-ID)
  • Ablaufstatus mit menschenlesbarem Countdown anzeigen
  • Dekodierte Abschnitte als formatiertes JSON kopieren

Beispiele

OAuth-2.0-Access-Token

Ausprobieren →

Ein typisches Access-Token mit Standard-Claims einschließlich Subjekt, Aussteller und Ablauf.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5

Tipps

  • JWS-Tokens (der häufigste Typ) sind signiert, aber nicht verschlüsselt. Jeder mit dem Token kann den Payload durch Base64-Dekodierung lesen.
  • JWE-Tokens verschlüsseln den Payload, sind aber weniger verbreitet. Dieses Tool dekodiert JWS-Tokens.
  • Überprüfen Sie Signaturen immer serverseitig, bevor Sie Claims vertrauen. Dieses Tool zeigt dekodierten Inhalt, verifiziert aber keine Signaturen.
  • Der "alg": "none"-Algorithmus ist ein Sicherheitsrisiko und sollte von Servern abgelehnt werden.
  • Symmetrische Algorithmen (HS256) verwenden ein gemeinsames Geheimnis; asymmetrische Algorithmen (RS256, ES256) verwenden öffentliche/private Schlüsselpaare.
  • Der "exp"-Claim ist ein Unix-Zeitstempel in Sekunden. Prüfen Sie ihn, um abgelaufene Tokens nicht zu akzeptieren.

Verstaendnis JWT-Decoder

JSON Web Tokens (JWTs) sind das dominierende Token-Format für moderne Web-Authentifizierung und -Autorisierung. Ein JWT ist ein kompakter, URL-sicherer String, der aus drei Base64url-kodierten Segmenten besteht, die durch Punkte getrennt sind: einem Header, der den Signaturalgorithmus angibt, einem Payload mit Claims über den Benutzer oder die Sitzung und einer kryptographischen Signatur, die sicherstellt, dass das Token nicht manipuliert wurde. Diese Struktur ermöglicht es jeder Partei, den Token-Inhalt durch einfache Base64-Dekodierung zu lesen, während nur Parteien mit dem Signaturschlüssel gültige Tokens erstellen oder verifizieren können.

Die meisten JWTs verwenden das JWS-(JSON Web Signature-)Format, bei dem der Payload signiert, aber nicht verschlüsselt ist. Das "alg"-Feld im Header gibt den Algorithmus an: Symmetrische Algorithmen wie HS256 verwenden ein gemeinsames Geheimnis, das sowohl dem Aussteller als auch dem Verifizierer bekannt ist, während asymmetrische Algorithmen wie RS256 und ES256 einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zur Verifizierung verwenden. Asymmetrische Algorithmen werden in verteilten Systemen bevorzugt, da der Verifizierungsschlüssel öffentlich geteilt werden kann, ohne den Signaturschlüssel zu kompromittieren.

Der Payload enthält registrierte Claims, die in RFC 7519 definiert sind: "iss" (Aussteller), "sub" (Subjekt), "aud" (Publikum), "exp" (Ablaufzeit), "nbf" (nicht vor), "iat" (ausgestellt am) und "jti" (JWT-ID). OAuth 2.0 und OpenID Connect fügen zusätzliche Claims für Scopes, Rollen und Benutzerprofil-Informationen hinzu. Der "exp"-Claim ist für die Sicherheit entscheidend — Tokens ohne Ablauf oder mit übermäßig langer Lebensdauer sind eine häufige Schwachstelle.

JWTs werden in OAuth-2.0-Access-Tokens, OpenID-Connect-ID-Tokens, API-Authentifizierung und Sitzungsverwaltung eingesetzt. Identity-Provider wie Auth0, Okta und Keycloak stellen JWTs aus, die Anwendungen verifizieren können, ohne den Provider zu kontaktieren, was zustandslose Authentifizierung ermöglicht. Das bedeutet jedoch auch, dass ein Widerruf schwierig ist — ein kompromittiertes Token bleibt gültig, bis es abläuft, weshalb kurze Ablaufzeiten und Token-Refresh-Flows wesentliche Sicherheitspraktiken sind.

Da JWS-Tokens Base64url-kodiert und nicht verschlüsselt sind, kann jeder, der das Token besitzt, den Header und Payload dekodieren und lesen. Sensible Informationen wie Passwörter, Kreditkartennummern und Geheimnisse sollten niemals in einem JWT-Payload platziert werden. JWE-(JSON Web Encryption-)Tokens verschlüsseln den Payload, sind aber in der Praxis weit weniger verbreitet. Die Unterscheidung zwischen Kodierung und Verschlüsselung ist eines der wichtigsten Konzepte beim Arbeiten mit JWTs.

Die Wahl des Signaturalgorithmus hat erhebliche Sicherheitsimplikationen. HS256 ist ein symmetrischer Algorithmus, der ein einzelnes gemeinsames Geheimnis sowohl zum Signieren als auch zur Verifizierung verwendet, was die Implementierung einfach macht, aber erfordert, dass beide Parteien dasselbe Geheimnis sicher speichern. RS256 und ES256 sind asymmetrische Algorithmen, die einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zur Verifizierung verwenden. In verteilten Systemen werden asymmetrische Algorithmen bevorzugt, da der öffentliche Schlüssel offen geteilt werden kann — oft über einen JWKS-(JSON Web Key Set-)Endpunkt — ohne den Signaturschlüssel zu kompromittieren. Die "alg": "none"-Option signalisiert ein unsigniertes Token ohne jegliche Signatur, was bedeutet, dass jeder Tokens mit beliebigen Claims fälschen kann. Ein bekannter Angriff besteht darin, den Algorithmus-Header auf "none" zu ändern und die Signatur zu entfernen. Server sollten den Algorithmus immer gegen eine Whitelist validieren und unsignierte Tokens ablehnen.

Korrektes Ablauf-Handling ist essenziell für die JWT-Sicherheit. Anwendungen sollten bei jeder Anfrage den "exp"-Claim prüfen, bevor sie dem Token vertrauen. Wenn ein Token abläuft, kann ein Refresh-Token (sicher gespeichert, oft in einem httpOnly-Cookie) verwendet werden, um ein neues Access-Token zu erhalten, ohne dass der Benutzer sich erneut anmelden muss. Kurze Access-Token-Lebenszeiten von typischerweise 5 bis 15 Minuten begrenzen das Expositionsfenster bei kompromittierten Tokens. Die proaktive Implementierung des Token-Refresh, bevor das Access-Token tatsächlich abläuft, vermeidet für den Benutzer spürbare Unterbrechungen in der Anwendung.

← Zurueck zu allen Tools