Best Practices für die sichere JWT-Implementierung

JWTs sind nur so sicher wie ihre Implementierung. Die Spezifikation ist flexibel; diese Flexibilität schafft Schwachstellen. Befolgen Sie die folgenden Best Practices, um die häufigen Fehler zu vermeiden, die in Produktivsystemen zu Umgehungen der Authentifizierung geführt haben.

Geben Sie den erwarteten Algorithmus immer ausdrücklich an: jwt.decode(token, key, algorithms=["RS256"]). Lesen Sie den Algorithmus niemals aus dem Token-Header aus, um den Verifizierungsschlüssel oder den Codepfad auszuwählen. Dies verhindert alg=none- und Schlüsselverwechslungsangriffe.

Access-Tokens: 15–60 Minuten. Refresh-Tokens: 7–30 Tage, gespeichert in httpOnly-Cookies (nicht in localStorage). Nach Ablauf verwendet der Client das Refresh-Token, um ohne erneute Authentifizierung ein neues Access-Token vom Authentifizierungsserver abzurufen.

Validieren Sie aud (Audience), um sicherzustellen, dass das Token für Ihren Dienst und nicht für einen anderen ausgestellt wurde. Validieren Sie iss (Issuer) gegen die URL Ihres Authentifizierungsservers. Ohne diese Prüfungen würde ein von einer anderen Anwendung stammendes Token akzeptiert, wenn es mit demselben Schlüssel signiert wurde.

Access-Tokens im Arbeitsspeicher (JS-Variable) — beim Schließen des Tabs gelöscht. Refresh-Tokens in httpOnly-, Secure-, SameSite=Strict-Cookies — für JavaScript nicht zugänglich. Speichern Sie JWTs niemals in localStorage — XSS kann sie stehlen.

JWTs sind zustandslos — es gibt keine integrierte Widerrufsmöglichkeit. Optionen: Führen Sie eine Widerrufsliste (Denylist), die bei jeder Anfrage geprüft wird; verwenden Sie eine sehr kurze Gültigkeitsdauer; oder verwenden Sie in Hochsicherheitskontexten opake Token mit zentraler Abfrage.

Rotieren Sie Signaturschlüssel regelmäßig. Veröffentlichen Sie mehrere Schlüssel mit unterschiedlichen kid-Werten in JWKS. Während der Rotation: Stellen Sie neue Token mit der neuen kid aus, lassen Sie den alten Schlüssel aktiv, bis alte Token abgelaufen sind, und entfernen Sie ihn anschließend aus JWKS.

Speichern Sie niemals sensible Daten (Passwörter, SSNs, Kreditkartendaten) in den JWT-Nutzdaten — sie sind base64url-codiert, nicht verschlüsselt. Verwenden Sie JWE (JSON Web Encryption), wenn Sie verschlüsselte Claims benötigen, oder bewahren Sie sensible Daten serverseitig auf.

Übertragen Sie JWTs ausschließlich über HTTPS. Ein über HTTP abgefangenes JWT ermöglicht die vollständige Umgehung der Authentifizierung. Setzen Sie das Secure-Flag für Cookies. Verwenden Sie HSTS, um eine Protokollherabstufung zu verhindern. Protokollieren Sie niemals vollständige JWT-Zeichenfolgen in Serverprotokollen.

Verwenden Sie gut gepflegte Bibliotheken: PyJWT 2+, python-jose, auth0/node-jsonwebtoken 9+, Nimbus JOSE + JWT (Java). Vermeiden Sie es, die JWT-Verifizierung selbst zu implementieren. Prüfen Sie regelmäßig CVE-Datenbanken auf Schwachstellen in Bibliotheken.

Testen Sie alle Angriffsvektoren: Senden Sie ein alg=none-Token, ein Token mit RS256→HS256-Verwechslung, ein abgelaufenes Token, ein Token mit falscher Audience und manipulierten Nutzdaten. Verwenden Sie jwt.io, um Test-Token zu erstellen. Fügen Sie Integrationstests hinzu, die bestätigen, dass diese mit 401 abgewiesen werden.

Wo sollten Refresh-Tokens in einer Webanwendung gespeichert werden?

Die sichere Verwendung von JWTs erfordert festgelegte Algorithmen, eine kurze Gültigkeitsdauer von Access-Tokens, die Speicherung von Refresh-Tokens in httpOnly-Cookies, die Validierung von Audience und Issuer sowie Schlüsselrotation. Als Nächstes: kryptografische Secret-Sharing-Verfahren.