JWT decodieren (Token auslesen)

So funktioniert es

Fügen Sie das Token genau so ein, wie Sie es kopiert haben; ein mitkopiertes Bearer- oder Authorization:-Präfix entfernt das Werkzeug selbst, und über mehrere Zeilen umbrochene Token werden wieder zusammengesetzt. Die Ausgabe zeigt drei Blöcke: den Header (Algorithmus und Typ), den Payload (die Angaben, die das Token trägt) und die Zeitangaben. Ein Payload mit "exp": 1817121600 etwa wird mit dem passenden Kalenderdatum versehen, und daneben steht, ob dieser Zeitpunkt schon verstrichen ist; iat (ausgestellt am) und nbf (nicht gültig vor) werden genauso umgerechnet. Das Token wird nie an einen Server gesendet — deshalb ist es unbedenklich, ein echtes Token aus einem System zu untersuchen, in dem Sie angemeldet sind. Was dieses Werkzeug bewusst nicht tut: die Signatur prüfen. Den Inhalt zu lesen beweist nichts über seine Unversehrtheit — die Prüfung verlangt den geheimen Schlüssel, und der gehört in keine Webseite eingefügt.

Dieses Werkzeug ist auch als jwt decodieren, jwt token auslesen, jwt decoder online, jwt online lesen, jwt ablauf pruefen bekannt.

Was ist JWT (JSON Web Token)?

Ein JWT ist ein dreiteiliges Textformat, das Identitäts- und Berechtigungsdaten zwischen zwei Systemen transportiert: Der Header nennt den Algorithmus, der Payload trägt die Angaben, die Signatur belegt, dass der Inhalt nicht verändert wurde. Die Teile sind durch Punkte getrennt und jeweils Base64URL-codiert — der Inhalt ist also verpackt, nicht verschlüsselt. Nach der Anmeldung gibt der Server dem Benutzer ein JWT; bei späteren Anfragen erkennt er ihn über die Signaturprüfung statt über eine Datenbankabfrage. Das macht das Token portabel, hat aber einen Preis: Wer das Token besitzt, kann bis zu dessen Ablauf unter dieser Identität auftreten.

Was ist Base64URL?

Base64URL ist eine Codierung, die Daten auf ein sicheres Alphabet aus Buchstaben, Ziffern, Bindestrich und Unterstrich abbildet; die Zeichen + und / des klassischen Base64 haben in Adressen eine Sonderbedeutung und wurden deshalb durch - und _ ersetzt, das abschließende =-Padding entfällt. Alle drei Teile eines JWT nutzen diese Codierung — darum übersteht ein Token Adresszeile, Cookie und HTTP-Header unbeschadet. Codierung ist keine Verschlüsselung: Jedes Werkzeug kann sie ohne Schlüssel umkehren — genau das tut diese Seite.

Was ist der Unterschied zwischen Decodieren und Verifizieren eines JWT?

Decodieren heißt, die Base64URL-Codierung umzukehren und zu lesen, was in Header und Payload steht; das braucht keinen Schlüssel, jeder kann es, und genau das tut dieses Werkzeug. Verifizieren heißt zu berechnen, ob Signatur, Inhalt und geheimer Schlüssel zusammenpassen: Ändert sich ein einziges Zeichen des Inhalts oder stammt die Signatur von einem anderen Schlüssel, schlägt die Prüfung fehl. Der Unterschied ist sicherheitskritisch — ein decodiertes Token sagt nur, was behauptet wird; ein verifiziertes Token beweist, dass die Behauptung vom Schlüsselinhaber signiert wurde. Serverseitig genügt Decodieren daher nie; die Signatur wird bei jeder Anfrage geprüft.

Trauen Sie decodiertem Inhalt nicht: Die Signatur wurde nicht geprüft

Die ersten beiden Teile eines JWT sind nicht verschlüsselt, sondern nur Base64URL-codiert; diese Codierung ist ein Umschlag, kein Schloss, und jeder kann ihn öffnen. Die Vertrauenswürdigkeit eines Tokens steckt im dritten Teil, der Signatur — einem mathematischen Prüfwert aus Inhalt und geheimem Schlüssel, den nur eine Partei mit dem Schlüssel verifizieren kann.

Dieses Werkzeug lässt die Prüfung mit Absicht weg, denn sie würde verlangen, dass Sie Ihren geheimen Schlüssel in eine Webseite einfügen — und ein Produktionsschlüssel gehört in keine Website, auch nicht in diese. Was Sie hier sehen, beantwortet die Frage 'was behauptet das Token'; ob das Token echt ist, kann nur Ihr Server beantworten, indem er die Signatur gegen den Schlüssel prüft.

Was bedeuten die Angaben im Payload?

RFC 7519 standardisiert eine Handvoll Feldnamen; alles Weitere ist anwendungsspezifisch. Diesen Feldern begegnen Sie am häufigsten:

• sub → Inhaber des Tokens (meist die Benutzerkennung)
• iss → das System, das das Token ausgestellt hat (Issuer)
• aud → das System, für das das Token bestimmt ist (Audience)
• exp → Ablaufzeitpunkt; danach weist der Server das Token zurück
• iat → Ausstellungszeitpunkt; der Abstand zu exp ist die Lebensdauer
• nbf → nicht gültig vor diesem Zeitpunkt (bei vordatierten Token)

Häufige Fragen

Wie decodiere ich ein JWT?

Fügen Sie das Token in das linke Feld ein — mehr ist nicht nötig. Header und Payload erscheinen sofort als formatiertes JSON, Zeitangaben wie exp und iat werden in lesbare Daten umgerechnet. Keine Einrichtung, kein Schlüssel erforderlich.

Wird mein Token an einen Server gesendet?

Nein. Das Decodieren läuft vollständig in Ihrem Browser, das Token wird nirgendwohin übertragen. Trotzdem Vorsicht: Ein noch gültiges Produktionstoken verschafft jedem, der es besitzt, eine Sitzung — schließen Sie die Seite, wenn Sie fertig sind.

Prüft dieses Werkzeug die Signatur?

Nein, bewusst nicht. Die Prüfung verlangt den geheimen Schlüssel, und geheime Schlüssel gehören nicht in eine Browserseite. Das Werkzeug zeigt nur den Inhalt; ob das Token wirklich von Ihrem Server stammt, kann nur Ihr Server bestätigen.

Woran erkenne ich, ob das Token abgelaufen ist?

Trägt der Payload ein exp-Feld, rechnet das Werkzeug es in ein Datum um und schreibt daneben, ob es abgelaufen ist oder nicht. Verglichen wird mit der Uhr Ihres Rechners — geht die falsch, stimmt auch das Urteil nicht.