Wer ein Login-System gebaut oder debuggt hat, ist dem JWT begegnet — einem kompakten Token, das zwischen Client und Server wandert, um zu beweisen, wer jemand ist. So funktioniert es und so liest man eines sicher.
Die drei Teile
Ein JWT sind drei durch Punkte verbundene Base64URL-Strings: header.payload.signature.
- Header — Metadaten, vor allem der Signaturalgorithmus, z. B.
{"alg":"HS256","typ":"JWT"}. - Payload — die Claims, ein JSON-Objekt mit Daten über den Nutzer und den Token.
- Signatur — eine kryptografische Signatur über Header und Payload, erzeugt mit einem Geheimnis (oder privaten Schlüssel), zur Erkennung von Manipulation.
Die ersten beiden Teile kannst du mit einem JWT-Decoder aufteilen und lesen.
Gängige Claims
Die Payload enthält Claims, einige standardisiert:
sub— Subjekt (meist die Nutzer-ID).iss— Aussteller (wer den Token erstellt hat).iat— Ausstellungszeit (ein Unix-Timestamp).exp— Ablaufzeit (ein Unix-Timestamp). Danach sollte der Token abgelehnt werden.aud— vorgesehene Zielgruppe.
Plus beliebige eigene Claims deiner App (Rollen, E-Mail usw.).
Wie JWTs zur Authentifizierung dienen
Typischer zustandsloser Ablauf: Du meldest dich an, der Server gibt ein signiertes JWT zurück, und dein Client sendet es bei jeder Anfrage mit (meist im Authorization: Bearer …-Header). Der Server verifiziert die Signatur und prüft exp — ist es gültig, vertraut er den Claims ohne Datenbankabfrage. Diese Zustandslosigkeit ist der Hauptvorteil.
Signiert, (meist) nicht verschlüsselt
Die meisten JWTs sind signiert (JWS), nicht verschlüsselt. Signieren beweist Integrität und Echtheit, aber die Payload ist nur Base64URL-kodiert — jeder kann sie lesen. Also:
- Lege nie Geheimnisse in die Payload (Passwörter, API-Schlüssel, private Daten).
- Verschlüsselung ist etwas anderes (JWE) und viel seltener.
Sicherheitsregeln, die zählen
- Verifiziere die Signatur immer serverseitig mit deinem geheimen/öffentlichen Schlüssel. Dekodieren (wie unser Tool) ist keine Verifizierung.
- Prüfe
exp. Ein abgelaufener Token muss abgelehnt werden. - HS256 vs. RS256: HS256 nutzt ein gemeinsames Geheimnis; RS256 signiert mit einem privaten und verifiziert mit einem öffentlichen Schlüssel — besser, wenn mehrere Dienste verifizieren, aber nicht ausstellen.
- Füge nie einen echten Schlüssel in ein Online-Tool ein. Einen Token zum Prüfen der Claims zu dekodieren ist in Ordnung; das Verifizieren braucht den Schlüssel und gehört in deinen eigenen Code.
Einen Token lesen
Zum Debuggen eines Auth-Problems — ist der Token abgelaufen? hat er die richtige Rolle? — dekodiere ihn und prüfe die Payload. Der kostenlose JWT-Decoder zeigt Header und Payload und wandelt exp in eine lesbare Zeit um, alles lokal im Browser, sodass der Token nie hochgeladen wird.