JWT-Struktur verstehen
Ein JSON Web Token (JWT) ist ein kompaktes, URL-sicheres Token-Format, das durch RFC 7519 definiert wird. Jedes JWT besteht aus drei durch Punkte getrennten Base64URL-kodierten Teilen: dem Header, dem Payload und der Signatur. Der Header deklariert den Algorithmus zur Signierung des Tokens (z. B. HS256, RS256, ES256) und den Token-Typ. Der Payload enthält Claims — Aussagen über das Subjekt oder das Token selbst.
Standard-registrierte Claims umfassen `iss` (Aussteller), `sub` (Subjekt), `aud` (Zielgruppe), `exp` (Ablaufzeit als Unix-Zeitstempel), `nbf` (nicht vor), `iat` (ausgestellt am) und `jti` (JWT-ID). Private Claims sind beliebige zusätzliche Schlüssel-Wert-Paare, die Ihre Anwendung benötigt, wie Benutzerrollen oder Mandanten-IDs. Der Decoder präsentiert alle Claims in einer menschenlesbaren JSON-Ansicht zusammen mit den rohen Base64URL-dekodierten Bytes.
Die Signatur ist das dritte Segment. Sie wird vom ausstellenden Server mit dem im Header deklarierten Algorithmus und einem Geheimnis oder privatem Schlüssel berechnet. Die Signatur stellt sicher, dass das Token während der Übertragung nicht manipuliert wurde. Dieser Decoder zeigt die rohen Signatur-Bytes an, verifiziert die Signatur jedoch nicht — die Verifizierung erfordert das serverseitige Geheimnis oder den öffentlichen Schlüssel.
Claims und Ablaufzeit lesen
Der `exp`-Claim ist ein numerischer Datumswert, der Sekunden seit der Unix-Epoche (1970-01-01T00:00:00Z) repräsentiert. Dieser Decoder wandelt ihn in einen menschenlesbaren UTC-Zeitstempel um, damit Sie sofort sehen können, wann das Token abläuft, ohne manuelle Berechnung. Ebenso werden `iat` und `nbf` als lesbare Datumsangaben dargestellt.
Der `aud`-Claim kann ein String oder ein String-Array sein, das die beabsichtigten Empfänger identifiziert. Wenn Ihre Anwendung ein Token erhält, bei dem `aud` nicht mit dem erwarteten Wert übereinstimmt, muss das Token abgelehnt werden. Der Decoder hebt das Audience-Feld hervor, damit Sie es während der Entwicklung oder beim Debugging schnell prüfen können.
Viele Identity-Provider betten nicht standardmäßige Claims ein: Azure AD enthält `oid`, `tid` und `roles`; Auth0 verwendet `https://`-Namespace-Claims; Cognito fügt `cognito:groups` hinzu. Die Payload-Ansicht zeigt jeden im Token vorhandenen Claim und gibt Ihnen vollständige Einsicht in das, was der Provider behauptet, ohne Dekodierungscode schreiben zu müssen.
Sicherheitsüberlegungen
Ein JWT zu dekodieren ist nicht dasselbe wie es zu validieren. Ein dekodiertes Token zeigt Ihnen die Claims, beweist aber nicht, dass das Token authentisch oder noch gültig ist. Die serverseitige Validierung muss die Signatur gegen das Geheimnis oder den öffentlichen Schlüssel prüfen, sicherstellen, dass `exp` nicht überschritten wurde, bestätigen, dass `iss` und `aud` mit erwarteten Werten übereinstimmen, und optional `nbf` prüfen. Vertrauen Sie niemals Claims eines nicht verifizierten Tokens.
Tokens können signiert (JWS) oder sowohl signiert als auch verschlüsselt (JWE) sein. Dieser Decoder verarbeitet JWS-Tokens — die gebräuchlichste Form in OAuth 2.0- und OpenID Connect-Flows. Wenn Sie ein JWE-Token (mit fünf durch Punkte getrennten Teilen) einfügen, ist der Payload Geheimtext und ohne Entschlüsselungsschlüssel unlesbar.
Vermeiden Sie es, Produktions-Tokens mit sensiblen Benutzerdaten in Online-Tools einzufügen. Dieser Decoder läuft vollständig in Ihrem Browser und sendet keine Daten an einen Server, was ihn für lokale Entwicklung und Debugging sicher macht. Für Produktions-Credentials bevorzugen Sie CLI-Tools wie `jwt-cli` oder Bibliotheks-Inspektionscode in Ihrer eigenen Umgebung.