JWT richtig einsetzen: häufige Sicherheitsfehler

JWT (JSON Web Token) ist ein verbreiteter Weg, Identitäts- und Berechtigungsinformationen zwischen APIs zu übertragen. Es sieht einfach aus: drei durch Punkte getrennte Teile. Die meisten Fehler entstehen aus dieser scheinbaren Einfachheit. Die folgende Liste sammelt die Punkte, die jedes Team prüfen sollte, das Token ausstellt und prüft; für detaillierte Empfehlungen siehe RFC 8725 zu den Best Practices der JWT-Sicherheit.

1. Ein JWT ist nicht verschlüsselt

Header und Payload eines signierten JWT sind nur base64url-kodiert; jeder kann sie lesen. Keine Passwörter, Ausweisnummern oder vertraulichen Geschäftsdaten in die Payload legen. Ist Vertraulichkeit nötig, nutzt man die verschlüsselte Form (JWE) oder trägt im Token nur eine Referenznummer und hält die Daten auf dem Server.

2. Dekodieren ist nicht Prüfen

Die Payload zu dekodieren und „Benutzer: ayse, Rolle: admin“ zu lesen, zeigt nicht, dass das Token echt ist. Vertrauen entsteht erst, nachdem die Signatur mit dem Schlüssel geprüft wurde. Servercode, der nur dekodiert und den Feldern vertraut, lässt jeden sein eigenes Token schreiben.

3. „alg“: „none“ und Algorithmenverwechslung

Das Feld alg im Header stammt vom Token selbst; ein Angreifer kann es ändern. Der Prüfer muss den akzeptierten Algorithmus aus seiner eigenen Konfiguration nehmen, nicht aus dem Header. „none“ darf nie akzeptiert werden, und ein mit einem öffentlichen Schlüssel signiertes Token (RS) darf nicht mit HS „geprüft“ werden, indem derselbe Schlüssel als Geheimnis dient.

4. Ablauf- und Zielgruppenfelder nicht prüfen

• Wird das Feld exp (Ablauf) nicht geprüft, bleibt das Token ewig gültig.
• Werden iss (Aussteller) und aud (Zielgruppe) nicht geprüft, gilt ein für einen anderen Dienst ausgestelltes Token auch bei Ihrer API.
• nbf (nicht vor) und Zeitabweichung: Ein paar Minuten Toleranz zwischen Servern genügen, keine Stunden.

5. Ein langlebiges Zugriffstoken

Ein Zugriffstoken sollte kurzlebig sein (Minuten), mit einem eigenen Refresh-Token zur Verlängerung der Sitzung. Ein gestohlenes langlebiges Token lässt sich mit voller Berechtigung nutzen, bis der Diebstahl bemerkt wird.

6. Der Speicherort

Ein Token im localStorage des Browsers fällt jedem Skript in die Hände, das in die Seite gelangt (XSS). In einem Cookie mit den Flags HttpOnly und Secure und passender SameSite-Einstellung können Skripte es nicht lesen; wer Cookies nutzt, muss aber zusätzlich an CSRF denken. Keine Option genügt allein.

7. Nicht widerrufen können

Ein JWT ist ein in sich geschlossenes Token; um es vor Ablauf zu entwerten, braucht der Server einen zusätzlichen Mechanismus (Sperrliste, Sitzungsversion, kurze Lebensdauer). Das Token eines Benutzers, der sich abmeldet oder dem die Berechtigung entzogen wird, bleibt bis zum Ablauf gültig; das im Entwurf akzeptieren oder schließen.

8. Ein schwacher HMAC-Schlüssel

Bei Verfahren mit gemeinsamem Schlüssel wie HS256 lässt sich ein erratbarer oder kurzer Schlüssel durch Offline-Ausprobieren knacken. Der Schlüssel sollte zufällig erzeugt, ausreichend lang und getrennt vom Code gespeichert sein.

So nutzen Sie das Werkzeug

Mit dem JWT-Decoder öffnen Sie ein Token im Browser und sehen Header, Payload, Zeitfelder und schwache Einstellungen; das Token wird nirgendwohin gesendet. Das Werkzeug dekodiert, es prüft nicht: Die echte Prüfung muss auf Ihrem Server mit dem Schlüssel erfolgen. Zum Ausprobieren der Signaturlogik gibt es die Webhook-HMAC-Signaturprüfung, für Schlüssel den Rechner für Passwortstärke und Entropie. Für die Überprüfung Ihrer API-Sicherheit schreiben Sie uns.