JWT ist nichts anderes als Base64 in einer Jacke – Entschlüsseln Sie es online in Sekunden

Du starrst auf eine Netzwerk-Abfrage. Es gibt einen Anfrageheader, der lautet Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c und deine erste Reaktion ist: „Was ist das überhaupt?“

Gutes Nachricht: Der größte Teil dieser Zeichenkette ist einfach Base64. Der erschreckende Blob trägt eine Manteljacke, als wäre er mysteriöser als er ist. Lassen wir ihn abziehen.

Was ein JWT tatsächlich ist

Ein JSON Web Token besteht aus drei Base64url-gekodeten Teilen, die mit Punkten verbunden sind:

• Kopfbereich – Algorithmus und Token-Typ (z. B. {"alg":"HS256","typ":"JWT"})
• Nutzlast – die Ansprüche: Benutzer-ID, Rollen, Ablauf, alles, was der Server entschieden hat, einzupacken
• Unterschrift – der Teil, der tatsächlich die Sicherheit gewährleistet

Der Header und der Payload sind nicht verschlüsselt. Sie sind Base64url-gekodet, was bedeutet, dass jeder, der den Token hat, sie lesen kann – ohne Schlüssel. Nur die Signatur verhindert Manipulation: eine Änderung eines einzigen Zeichens im Payload macht den Token ungültig.

Um den Payload jetzt zu decodieren: nimm den zweiten Teil (zwischen den zwei Punkten), füge ihn in einen Base64-Decodiererein und du siehst klare JSON. Das ist alles. Das ist das Magie-Trick.

Wie man ein JWT in Sekunden decodiert

Der schnellste Weg: füge deinen Token in den JWT-Decodierer von IOTools ein. Er teilt die drei Teile, decodiert jeden und zeigt den Header und den Payload als formatierten JSON an – ohne Konto, ohne Setup, ohne „Anmeldung, um den Decoder zu entsperren“.

Das, was du sofort in einem typischen Payload siehst:

• sub – Subject (normalerweise Benutzer-ID)
• iat – issued-at-Timestamp (Unix-Epoch)
• exp – Ablauf-Timestamp
• iss – Aussteller
• Jede benutzerdefinierte Aussage, die dein API hineinsteckt: Rollen, Berechtigungen, Planstufe usw.

Wenn du nur wissen willst, ob ein Token abgelaufen ist, ohne ein vollständiges Decodierwerkzeug zu konfigurieren, dann nutze den JWT-Ablauf-Prüfer um den exp Anspruch zu lesen und genau zu sehen, wie viel Lebenszeit noch bleibt – oder wann er bereits abgelaufen ist.

Die drei Dinge, die Entwickler verwirren

1. Die Ablaufzeit, die du vergessen hast zu überprüfen

Der exp Das Feld ist einfach eine Zahl im Payload – der Server sollte sie validieren, aber viele alte Codebasen tun das nicht oder haben einen Fehler im Zeitzone-Handling. Wenn Benutzer plötzlich ausgeloggt werden (oder plötzlich für immer eingeloggt bleiben), decodiere den Token und vergleiche exp mit dem aktuellen Unix-Timestamp. Der Ablauf-Prüfer t das in einem Klick.

2. Algorithmus-Verwirrung

Der Header-Field gibt dem Verifizierer an, welchen Algorithmus zu verwenden ist. Einige ältere JWT-Bibliotheken akzeptierten alg und ignorierten die Verifikation komplett – sie entfernten die Signatur und betrachteten den Payload als gültig. Dies ist ein bekannter Angriff. Stets überprüfe, dass deine Bibliothek eine spezifizierte Algorithmus-Liste erzwingt und {"alg":"none"} ablehnt none.

Ein anderes Beispiel: RS256 (asymmetrisch) vs HS256 (symmetrisch). Ein Angreifer, der dein öffentliches Schlüssel kennt, kann ein Token fälschen, indem er den Header auf HS256 umstellt und mit dem öffentlichen Schlüssel als Geheimwort signiert – falls die Bibliothek naiv auf die Aussage im Header vertraut. Die Lösung: Konfiguriere deine Bibliothek mit einem expliziten Algorithmus, nicht „was der Token sagt“. alg 3. Geheime Werte im Payload

Da der Payload Base64-gekodet und nicht verschlüsselt ist, ist alles, was du darin speicherst, für den Client lesbar (und für jeden, der den Token über normales HTTP abholt, obwohl du HTTPS überall verwendest, oder?). Stelle keine Passwörter, PII oder interne Systemdetails in JWT-Aussagen. Der Payload dient zur Authentifizierung, nicht als Ort, um sensible Daten zu speichern.

Decodiere einen Token aus deiner eigenen App und schau, was darin ist. Du könntest überrascht sein, was ein früherer Entwickler vor Jahren hineingelegt hat.

JWT vs Session-Tokens: Was tatsächlich anders ist

Der ewige Streit. Hier ist ein direktes Vergleich:

JWT

	Session-Token	Wo der Zustand liegt
Im Token (stateless)	Auf der Serverseite (Datenbank oder im Speicher)	Revokation
Schwer – der Token ist gültig bis	es es, wenn du eine Blacklist pflegst exp Leicht – lösche einfach die Sitzung	Gut für verteilte Systeme; kein gemeinsamer Sitzungs-Store erforderlich
Skalierbarkeit	Erfordert sticky Sessions oder gemeinsame Speicher (Redis usw.)	Sichtbarkeit des Payloads
Der Client kann die Aussagen lesen (nicht verschlüsselt)	Unzugänglich für den Client	Speicher-Risiko
localStorage ist XSS-gefährdet; httpOnly-Cookie ist sicherer	httpOnly-Cookie (Standardansatz)	Größe des Tokens
Größer – trägt alle Aussagen direkt mit	Klein – nur eine ID	Am besten für
APIs, Microservices, Authentifizierung über mehrere Domänen	Traditionelle server-seitige Webanwendungen	Kein System ist universell besser. JWTs überzeugen, wenn du stateless Authentifizierung über mehrere Dienste brauchst. Session-Tokens sind einfacher, wenn du die gesamte Stack kontrollierst und sofortige Revokation benötigst (z. B. „überall ausloggen“ bei einem Sicherheitsvorfall).

JWTs im echten Arbeitsablauf debuggen

Hier ist die typische Reihenfolge, wenn etwas in einer API mit JWTs schiefgeht:

Kopiere den Token

1. aus dem fehlenden Request (Authorization-Header, Query-Parameter oder Cookie – wo immer dein API ihn speichert) Füge ihn in den
2. ein, um die Rohansprüche zu sehen JWT-Decodierer – ist der Token abgelaufen? Nutze den
3. Prüfen exp wenn du keine Unix-Timestamp-Rechnung im Kopf machen willst Ablauf-Prüfer – stimmt der Aussteller und der Ziele mit dem, was dein Dienst erwartet, überein?
4. Prüfen iss und aud Prüfe den Algorithmus
5. im Header – stimmt er mit deiner Serverkonfiguration überein? Prüfe das Signaturformat
6. – drei Teile? Zwei? Ein gefälschter Token zeigt manchmal als zwei Teile ohne Signatur auf Die meisten JWT-Debugging-Situationen enden bei Schritt 3. Der Token wurde mit kurzer TTL ausgestellt, ist irgendwo im Cache, und ist abgelaufen. Das ist langweilig und häufig.

Die Signatur: Der einzige Teil, der wichtig ist

Die Signatur wird berechnet als:

. Der Server erzeugt sie beim Ausstellen des Tokens. Bei der Validierung berechnet er denselben Hash und vergleicht ihn. Wenn der Payload in irgendeiner Weise verändert wurde – selbst ein einziger Buchstabe – passt der Hash nicht mehr und der Token wird abgelehnt. HMACSHA256(base64url(header) + "." + base64url(payload), secret)Daher ist das Lesen der Aussagen aus einem JWT sicher und einfach, aber das Fälschen eines Tokens ohne das Geheime ist nicht möglich. Der Base64 ist die Kleidung; die Signatur ist das Schloss an der Tür.

Bei asymmetrischen Algorithmen (RS256, ES256) ist der Signier-Schlüssel ein privater Schlüssel, der nie vom Auth-Server verlässt. Der Verifizierungsschlüssel ist ein öffentlicher Schlüssel, den jedes Service verwenden kann – kein gemeinsamer Geheimnis erforderlich. Dies ist die richtige Architektur für Microservices, bei denen mehrere Dienste die Token überprüfen, aber nur ein einziger sie ausstellt.

JWT ist nichts anderes als Base64 in einer Manteljacke – Decodiere es online in Sekunden 2

Das könnte Ihnen auch gefallen