JWT-Tools für Entwickler Decodieren, Codieren und Ablaufzeit prüfen

Jeder Backend-Entwickler hat das schon erlebt: Eine 401 Unauthorized erscheint in der Konsole und die Runde beginnt. Ist der Token abgelaufen? Wurde er mit dem falschen Geheimnis signiert? Hat der Payload einen Claim verloren, während er zwischen den Diensten übertragen wurde? JWTs – JSON Web Tokens – sind das Bindeglied der modernen Authentifizierung, und wenn sie kaputt gehen, geht alles hinter der Authentifizierungsbarriere aus.

Das Problem ist nicht, dass JWTs komplex sind. Die Struktur ist eigentlich einfach: drei base64url-gekodete Abschnitte, verbunden durch Punkte – Header, Payload, Signatur. Das Problem ist, dass ein rohes Token wie eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTc0NjA5NjAwMH0.mK2xVpQ8nZ3aF7tLdRhW6sYbcXeUoIPjNvGqTmAS1kE nichts sagt, bis man es entschlüsselt. Und das Entschlüsseln – schnell, im Browser, ohne etwas zu installieren – ist genau das, was diese drei kostenlosen Werkzeuge bewältigen.

Diese Anleitung führt durch das vollständige JWT-Workflow: Ein Token entschlüsseln, um zu sehen, was drin ist, ein Token generieren, um Authentifizierung in Tests zu simulieren, und Ablaufzeit prüfen, um Zeitüberschreitungsfehler zu diagnostizieren. Jeder Abschnitt verwendet das oben genannte Beispiel-Token, damit Sie Schritt für Schritt folgen können.

Werkzeug 1 – JWT-Decoder: Sofortiges Inspektion jedes Tokens

Der JWT-Decodierer teilt jedes Token in seine drei Komponenten auf und entschlüsselt den Header und den Payload aus base64url zu lesbarem JSON.

Fügen Sie das obige Beispiel-Token ein und Sie sehen den Header entschlüsselt zu:

{
  "alg": "HS256",
  "typ": "JWT"
}

Und den Payload:

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1746096000
}

Das exp ist eine Unix-Zeitstempel. Auf den ersten Blick bedeutet es nichts – aber der Decoder konvertiert es in ein menschliches Lesbarkeit, sodass Sie sofort erkennen, ob das Token noch gültig ist oder bereits veraltet ist.

Eines zu verstehen: Der Decoder prüft standardmäßig nicht die Signatur Durch die Prüfung der Signatur werden das Geheimnis (für HS256) oder das öffentliche Schlüssel (für RS256/ES256) benötigt. Was der Decoder Ihnen gibt, ist der entschlüsselte Inhalt – was Sie benötigen, wenn Sie ein 401 debuggen, prüfen, welche Ansprüche enthalten waren, oder ein Token von einem Drittanbieter-Identitätsanbieter inspizieren.

Wichtiger Hinweis: Der JWT-Payload ist base64url-gekodet, nicht verschlüsselt. Jedes Werkzeug (oder jede Person) mit dem Token kann den Payload lesen, ohne das Geheimnis. Die Signatur beweist nur, dass das Token nicht verändert wurde. Deshalb sollten Sie keine sensible Daten – Passwörter, Kreditkartennummern, SSNs – im JWT-Payload speichern.

Werkzeug 2 – JWT-Encoder: Erstellen von Tokens für Tests

Der JWT-Encoder macht das Gegenteil: Sie geben einen JSON-Payload, wählen einen Algorithmus (HS256 ist der Standard) und geben ein Geheimnis ein, und das Werkzeug generiert ein signiertes Token, das Sie sofort verwenden können.

Der häufigste Anwendungsfall ist die Simulation von Authentifizierung in Tests. Stellen Sie sich vor, dass Ihre Integrationstests einen geschützten API-Endpunkt erreichen müssen. Anstatt ein echtes Login-Verfahren zu verbinden, erstellen Sie ein Token mit genau den Ansprüchen, die der Endpunkt erwartet:

{
  "sub": "test_user_001",
  "role": "editor",
  "iat": 1746009600,
  "exp": 1746096000
}

Signieren Sie es mit Ihrem Testgeheimnis, fügen Sie das resultierende Token in Ihre Testheader ein und Ihre geschützten Routen reagieren, als wäre ein echter Benutzer authentifiziert. Keine Simulation des Authentifizierungsmitteils, keine Startung eines Identitätsanbieters – nur ein gültiges Token mit den benötigten Ansprüchen.

Der Encoder ist auch nützlich, wenn Sie ein neues Dienst entwickeln und manuell testen möchten, wie er bestimmte Claim-Kombinationen verarbeitet: fehlende Rollen, abgelaufene Tokens, unerwartete Bereiche. Erstellen Sie Tokens mit Randfall-Payloads und werfen Sie sie an Ihr Middleware, um zu sehen, wie es reagiert.

Wenn Sie das base64url-Verfahren selbst verstehen müssen – da der JWT-Payload nur gekodet, nicht verschlüsselt ist – bietet der base64-Decoder die Möglichkeit, den Payload-Abschnitt manuell zu entschlüsseln. Fügen Sie den mittleren Teil jedes Tokens (den Payload-Abschnitt) in den base64-Decoder ein und Sie erhalten den Roh-JSON-Wert zurück. Gleiches Verfahren, Schritt für Schritt.

Werkzeug 3 – JWT-Ablaufzeit-Prüfer: Debuggen von 401-Fehlern ohne Rechnung

Die Ablaufzeit verursacht eine große Zahl an Authentifizierungsfehlern in der Produktion. Der JWT-Ablauf-Prüfer nimmt jedes Token und sagt Ihnen sofort: Ist es abgelaufen? Wenn ja, um wie viel?

Fügen Sie das Beispiel-Token ein und der Prüfer extrahiert das exp Feld, konvertiert es aus einem Unix-Timestamp in ein lesbares Datum und vergleicht es mit der aktuellen Zeit. Sie erhalten einen klaren Status: gültig (mit verbleibender Zeit) oder abgelaufen (mit der Zeit, seitdem es abgelaufen ist).

Das ist wichtiger, als es klingt. Wenn eine 401 in der Produktion auftritt, ist die erste Frage immer: Ist das Token abgelaufen oder ist etwas anderes schiefgelaufen? Die Antwort auf diese Frage durch mentale Rechnung mit einem Unix-Timestamp – 1746096000 - current_time / 3600 – verbraucht Zeit und führt zu Fehlern. Der Ablaufzeit-Prüfer gibt die Antwort in einem einzigen Eintrag.

Er zeigt auch das iat (erstellt am) Datum an, wenn vorhanden, sodass Sie genau sehen, wann das Token erstellt wurde und wie lange die Sitzung aktiv war. Nützlich beim Debuggen von Token-Refresh-Fehlern oder beim Finden, warum eine langfristige Sitzung plötzlich fehlgeschlagen ist.

Zusammenfassung: Ein typischer Debug-Workflow

Sie erhalten eine 401. Hier ist der schnellste Weg von Fehler zu Lösung:

1. Prüfen Sie zuerst die Ablaufzeit. Fügen Sie das Token in den Ablauf-Prüfer. Wenn es abgelaufen ist, ist die Lösung ein Token-Auffrischung – keine weiteren Debugging-Arbeiten nötig.
2. Inspektieren Sie den Payload. Wenn das Token noch gültig ist, fügen Sie es in den JWT-Decodiererein. Prüfen Sie die Ansprüche: Ist der sub korrekt? Ist der erwartete role oder scope vorhanden? Ist das Publikum (aud) richtig für den Endpunkt, den Sie erreichen?
3. Reproduzieren Sie mit einem benutzerdefinierten Token. Wenn Sie vermuten, dass eine bestimmte Claim-Kombination die Ablehnung verursacht, erstellen Sie ein Token mit dem Encoder und testen Sie direkt. Dies isoliert, ob es die Inhalt der Ansprüche oder die Struktur des Tokens ist, die den Fehler verursacht.

Drei Werkzeuge, unter einer Minute, ohne Installation. Die meisten JWT-verwandten 401-Fehler werden auf Schritt 1 oder 2 gelöst.

Das könnte Ihnen auch gefallen

Neu

TypeScript-Hilfsarten — Die Werten zu merken (und die Reste)

Mehr lesen "

Aktualisiert am 17. Juni 2026

Neu

git stash — Mehr als ein Panik-Speicher (Teilweise Stash, benannte Stashes und der Rest)

Mehr lesen "

Aktualisiert am 16. Juni 2026

Neu

Cursor-basiert gegen Offset-Verzeichnis – Warum wird bei page=2 automatisch Datensätze gelöscht

Mehr lesen "

Aktualisiert am 15. Juni 2026

Neu

Docker-Multi-Stage-Builds: Verkleinern Sie Ihr Image ohne die Bereitstellung zu stören

Mehr lesen "

Aktualisiert am 14. Juni 2026