JWT-Payload ohne Signaturprüfung dekodieren

Beide Bereiche werden als strukturierte Objekte ausgegeben, sodass Sie Claims, Kennungen, Zeitangaben, Aussteller, Zielgruppen und Algorithmusmetadaten leicht untersuchen oder weiterverarbeiten können. Die Signatur wird bewusst nicht geprüft. Die dekodierten Werte zeigen daher nur, was das Token behauptet, und beweisen nicht, wer es erstellt hat. Verwenden Sie das Ergebnis zur Fehlersuche, Entwicklung, Dokumentation und sorgfältigen Prüfung, niemals als Nachweis für Authentizität oder Berechtigung.

Verstehen Sie die Aussagekraft der Dekodierung

Ein JWT besteht gewöhnlich aus Header, Payload und Signatur, die durch Punkte verbunden sind. Die ersten beiden Segmente enthalten base64url-kodiertes JSON. Der Inhalt ist damit kompakt transportierbar, aber weder verschlüsselt noch verborgen. Diese Funktion zerlegt das eingegebene Token, dekodiert die ersten beiden Segmente als UTF-8, parst ihr JSON und gibt die resultierenden Header- und Payload-Objekte zurück. Das dritte Segment wird nicht zur Authentifizierung verwendet. Dieser Unterschied ist entscheidend, denn jeder kann eine tokenähnliche Zeichenfolge mit beliebigen Claims erstellen. Ein Betreff, eine Rolle, ein Aussteller, eine Zielgruppe oder ein Ablaufwert im dekodierten Payload beweist nicht, dass ein vertrauenswürdiges System das Token ausgestellt hat. Nutzen Sie die Dekodierung, um die Tokenstruktur sichtbar zu machen, Claim-Namen und -Werte zu untersuchen oder während der Entwicklung eine lesbare Darstellung zu erhalten. Wenn eine Sicherheitsentscheidung vom Token abhängt, verwenden Sie eine geeignete JWT-Prüfbibliothek mit einem ausdrücklich vertrauenswürdigen Schlüssel sowie festen Vorgaben für Algorithmus, Aussteller und Zielgruppe.

Geben Sie ein kompaktes JWT ein und lesen Sie die Antwort

Fügen Sie das vollständige kompakte JWT in das Feld token ein. Ein strukturell gültiges Token hat genau drei Segmente, die durch zwei Punkte getrennt sind, obwohl dieser Decoder nur die ersten beiden liest. Die Antwort enthält ein header-Objekt und ein payload-Objekt. Typische Header-Felder sind typ für den JWT-Medientyp und alg für den behaupteten Signaturalgorithmus. Häufige Payload-Felder sind sub für das Subjekt, iss für den Aussteller, aud für die Zielgruppe, exp für die Ablaufzeit sowie anwendungsspezifische Claims. Der Decoder verlangt keinen bestimmten Claim und erhält vorhandene JSON-Werte unverändert. NumericDate-Claims wie exp, nbf und iat bleiben Zahlen und werden nicht in Datumsangaben umgewandelt. So wird nicht vorweggenommen, wie Sie diese anzeigen oder vergleichen möchten. Bei einer falschen Segmentzahl, fehlerhaftem base64url, ungültigem UTF-8 oder JSON sowie bei einem dekodierten Bereich, der kein Objekt ist, liefert die Anfrage einen Fehler für ungültige Eingaben statt eines unvollständigen Ergebnisses.

Verwenden Sie dekodierte Claims sicher

Die Dekodierung ist besonders an Systemgrenzen nützlich. API-Entwickler können die Claims eines Identitätsanbieters mit den von einer Anwendung erwarteten Namen vergleichen. Der Support kann ein bereinigtes Test-Token untersuchen, um eine fehlende Zielgruppe oder einen fehlenden Scope zu erkennen. Eine Testsuite kann lokal erzeugte Fixture-Tokens dekodieren und erforderliche benutzerdefinierte Claims prüfen, bevor die kryptografische Verifikation separat getestet wird. Halten Sie die Sicherheitsgrenze in jedem Ablauf ausdrücklich fest: Dekodierte Daten sind nicht vertrauenswürdige Eingaben. Gewähren Sie keinen Zugriff, wählen Sie keinen Tenant, akzeptieren Sie keine Identität und geben Sie keine privaten Daten allein aufgrund eines dekodierten Claims frei. Kopieren Sie echte Bearer-Tokens nicht in Logs, Tickets, Chats oder gemeinsame Dokumente, denn ein JWT kann trotz harmlos wirkendem Payload eine aktive Zugangsinformation sein. Verwenden Sie zur Fehlersuche vorzugsweise synthetische, abgelaufene oder lokal erzeugte Beispiele. Muss eine Automatisierung echte Tokens verarbeiten, übertragen Sie diese ausschließlich über einen angemessen geschützten Kanal und führen Sie anschließend eine Prüfung mit vertrauenswürdiger Konfiguration durch.