JWT Security Best Practices: JSON Web Tokens sicher implementieren

JSON Web Tokens (JWTs) sind kompakt und praktisch, aber Fehler bei Signatur, Speicherung oder Validierung führen schnell zu Account-Übernahmen. Dieser Leitfaden erklärt den Aufbau von JWTs, typische Stolperfallen und ein sicheres Vorgehen für Produktion.

1. JWT-Struktur im Überblick

Ein JWT besteht aus drei Base64URL-kodierten Teilen: header.payload.signature. Der Header definiert den Algorithmus, der Payload enthält Claims, die Signatur bindet beides.

2. Signaturalgorithmen wählen

• Bevorzugt asymmetrisch: RS256 oder ES256 für sauberes Key-Management.
• none und schwache/Legacy-Algs vermeiden. Algorithmus-Downgrades serverseitig blockieren.
• Erlaubte Algorithmen beim Verifizieren strikt whitelisten.

3. Ablauf und Refresh-Strategie

• Access Tokens kurz halten (5–30 Minuten).
• Refresh Tokens mit Rotation und Wiederverwendungs-Erkennung; bei Verdacht komplette Kette sperren.
• iat und nbf setzen, um vorzeitige oder wiederholte Nutzung zu verhindern.

4. Sichere Speicherung auf Clients

• Im Browser httpOnly, secure Cookies mit SameSite=Lax/Strict statt localStorage nutzen, um XSS-Folgen zu mindern.
• In Mobile/Desktop-Apps OS-Secure-Storage verwenden; keine Secrets im Binary.
• Tokens bei Logout und Rotation löschen.

5. Serverseitige Validierung

• Signatur mit korrektem Key und erlaubtem Alg prüfen.
• exp, nbf, iss, aud und sub gegen erwartete Werte validieren.
• Tokens nur über TLS akzeptieren.
• Tokens mit fehlenden oder unerwarteten kritischen Claims ablehnen.

6. Häufige JWT-Schwachstellen vermeiden

• Algorithm-Confusion: Erlaubte Algs fest verdrahten; Header-Angaben ignorieren.
• Key-ID (kid) Missbrauch: kid gegen Whitelist prüfen; keine Dateisystemzugriffe basierend auf kid.
• Replay: Kurzlebige Access Tokens mit serverseitigen Revocation-Listen kombinieren.
• CSRF: SameSite-Cookies oder CSRF-Tokens für state-changing Requests einsetzen.

7. Token-Revocation-Strategien

• Blocklist für widerrufene Refresh Tokens (oder deren IDs) führen.
• Signaturschlüssel regelmäßig rotieren; JWKS-Endpunkt mit Key-Rollover bereitstellen.
• Sessions nach Passwortänderungen, MFA-Resets oder verdächtiger Aktivität ungültig machen.

8. Debugging und Observability

• Token-Metadaten loggen (Issuer, Audience, kid, exp), nicht den kompletten Token.
• Verifizierungsfehler mit Gründen tracken, um Config-Drift oder Angriffe zu erkennen.
• Das Tool jwt-decoder nutzen, um Header/Claims sicher zu inspizieren, ohne unsichere Drittquellen.

9. Deployment-Checkliste

• Kurzlebige Access Tokens; rotierende Refresh Tokens
• Strenge Alg-Allowlist; RS256/ES256 bevorzugt
• Claims validiert (iss, aud, exp, nbf, sub)
• Sichere Cookie-Speicherung; TLS erzwungen
• Revocation/Blocklist und Key-Rotation geplant

10. Secure-by-default-Rezept

1. RS256-Tokens mit 15-Minuten-Expiry ausstellen.
2. Access Tokens in httpOnly SameSite=Lax Cookies speichern.
3. Refresh Tokens bei jeder Nutzung rotieren; Wiederverwendung erkennen.
4. JWKS mit aktuellem + nächstem Key bereitstellen; vierteljährlich oder nach Incidents rotieren.
5. Mit jwt-decoder in der Entwicklung Claim-Sets prüfen, bevor sie live gehen.