Aufbau eines JWT
Ein JSON Web Token (RFC 7519) besteht aus drei Base64URL-kodierten Teilen, durch Punkte verbunden: Header.Payload.Signatur. Der Header nennt den Algorithmus, mit dem signiert wurde. Die Payload ist ein JSON-Objekt mit Claims über das Subjekt. Die Signatur deckt die ersten beiden Teile ab, sodass ein Prüfer erkennt, ob etwas verändert wurde.
Die ersten beiden Teile sind nur kodiert, nicht verschlüsselt. Wer das Token hat, kann jeden Claim lesen; deshalb funktioniert dieser Decoder ohne Schlüssel, und deshalb darf ein JWT nie Geheimnisse enthalten.
Standard-Claims
| Claim | Bedeutung |
|---|---|
| iss | Issuer: wer das Token erstellt hat |
| sub | Subject: um wen es im Token geht, meist eine Benutzer-ID |
| aud | Audience: für welchen Dienst das Token bestimmt ist; Prüfer müssen das kontrollieren |
| exp | Ablauf als Unix-Zeitstempel in Sekunden |
| nbf | Not before: das Token ist bis zu diesem Zeitpunkt ungültig |
| iat | Ausgestellt am |
| jti | Eindeutige Token-ID, für Sperrlisten |
Signaturalgorithmen
HS256 (HMAC mit SHA-256) verwendet ein gemeinsames Secret zum Signieren und Prüfen; wer prüfen kann, kann also auch fälschen. Es passt für einen Dienst, der mit sich selbst spricht. RS256, ES256 und EdDSA signieren mit einem privaten und prüfen mit einem öffentlichen Schlüssel. Das nutzen Identity-Provider (Auth0, Keycloak, Google, Azure AD), damit jeder Dienst Tokens prüfen kann, ohne welche ausstellen zu können. Die öffentlichen Schlüssel liegen meist unter einer /.well-known/jwks.json-URL.
Was Prüfer kontrollieren müssen
- Die Signatur, mit einem zum
algim Header passenden Schlüssel, und niemals"alg": "none"akzeptieren. - Dass
expin der Zukunft undnbf, falls vorhanden, in der Vergangenheit liegt (mit etwas Toleranz für Uhrenabweichung). - Dass
issundauddie erwarteten Werte haben.
Fragen
Kann ich mein Token hier gefahrlos einfügen?
Das Token wird von JavaScript in Ihrem Browser dekodiert und nicht übertragen. Trotzdem ist ein Token ein Zugangsnachweis: Behandeln Sie es wie ein Passwort und nehmen Sie zum Debuggen lieber kurzlebige Test-Tokens.
Warum sagt der Decoder, mein Token sei abgelaufen?
Sein exp-Claim liegt vor der Uhrzeit Ihres Computers. Tokens sind meist kurzlebig (Minuten bis Stunden); holen Sie ein frisches vom Login- oder Refresh-Endpunkt. Geht Ihre Uhr falsch, ist auch die Prüfung falsch.
Kann ich hier ein RS256-Token verifizieren?
In dieser Version nicht. RS256 braucht den öffentlichen Schlüssel des Ausstellers (von dessen JWKS-Endpunkt). Der Decoder zeigt Header, Payload und Zeitprüfungen für jeden Algorithmus; nur HMAC-Algorithmen lassen sich mit einem Secret verifizieren.
Warum ist die Payload ohne Secret lesbar?
Weil ein JWT signiert ist, nicht verschlüsselt. Base64URL ist absichtlich umkehrbar. Muss der Inhalt verborgen bleiben, muss das Token als JWE verschlüsselt werden, das ähnlich aussieht, aber fünf Teile hat.
Was bedeutet der Zeitstempel in exp?
Sekunden seit dem 1. Januar 1970 UTC (Unix-Zeit). Der Decoder wandelt ihn in ein Datum Ihrer Zeitzone um und zeigt die verbleibende Zeit. Für andere Werte gibt es das Unix-Zeitstempel-Tool.