JWT: Struktur und Schwachstellen

1) Was ist JWT und wo wird es verwendet?

JWT ist ein kompakter, autarker Claims Container (Claims) im Format 'Base64Url (Header). Base64Url(payload). Base64Url(signature)`.

• JWS (signierte Token - Authentizität/Integrität),
• JWE (verschlüsselte Token - Datenschutz),
• OIDC/OAuth2 als Access/ID-Token sowie Service-to-Service-Authentifizierung.

Vorteile: Autonomie, Cache-Fähigkeit, geringer Overhead. Nachteile: Risiko falscher Validierung, komplexe Rückruffälle.

2) JWT-Struktur

2. 1 Header (Header, JSON)

Minimal: Algorithmus und Schlüssel-ID.

json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

'alg': Signatur-/Verschlüsselungsalgorithmus (RS256/ES256/PS256/HS256 usw.).
'kid': Zeiger auf den Schlüssel (für JWKS-Rotation).
Optionale Schlüsselquellen: 'jku', 'x5u' (siehe Sicherheitslücken § 6. 3).

2. 2 Nutzlast (Payload, JSON)

• `iss` (issuer), `aud` (audience), `sub` (subject)
• „exp“ (Ablaufzeit), „nbf“ (nicht früher), „iat“ (ausgestellt)
• „jti“ (Token-ID, für Bewertungen geeignet)
• Domain-Stempel: 'scope/roles', 'tenant', 'kyc _ level' usw.

2. 3 Unterschrift (signature)

JWS = `sign(base64url(header) + "." + base64url(payload), private_key)`

Verifizierung: Mit einem streng passenden öffentlichen Schlüssel und genau dem Algorithmus, den der Server erwartet.

3) Grundlegende Validierungsinvarianten

1. Der Algorithmus wird durch die Konfiguration des Ressourcenservers (allow-list) festgelegt und nicht dem Inhalt des' header 'vertraut. alg`.
2. Überprüfen Sie' iss' und 'aud' auf genaue übereinstimmung,' exp/nbf'- unter Berücksichtigung der kleinen 'clock _ skew' (± 30-60s).
3. Verweigern Sie Token ohne' kid' nur, wenn der einzelne Schlüssel und keine Rotation; ansonsten "kid' verlangen.
4. Vertrauen Sie keinem Stigma ohne Autorisierung auf Objektebene (BOLA-first).
5. Parsing - nach dem Krypto-Check; grundlegende Größenprüfungen vor der Decodierung.

4) JWS vs JWE

JWS: unterzeichnet, aber lesbar. Legen Sie keine payload PII/Geheimnisse.
JWE: verschlüsselt payload; Integration ist schwieriger, das Schlüsselmodell ist kritisch.
In den meisten APIs reicht ein JWS + Verbot sensibler Daten im Payload.

5) Lebenszyklus des Tokens

Zugang: kurze Zeit (5-30 Minuten).
Refresh: länger (7-30 Tage), rotate-on-use (Einweg), speichern Sie die "schwarze Liste" "jti/sid'.
Revocation: Listen 'jti' mit TTL, Introspektion für opaque-Token, Abkürzung 'exp' bei Vorfällen.
Schlüsselrotation: JWKS mit Überlappung (alt + neu), siehe Artikel „Schlüsselrotation“.

6) Häufige Schwachstellen und wie man sie schließt

6. 1 'alg = none '/Algorithmus-Ersatz

Fazit: Der Server vertraut dem Feld 'alg' und akzeptiert ein unsigniertes Token.
Schutz: starre allow-list Algorithmen auf dem Server; 'none' und unerwartete Werte ablehnen.

6. 2 RS256→HS256 Swap (Symmetrie)

Die Quintessenz: Der Angreifer ersetzt „alg“ durch HS256 und verwendet den öffentlichen Schlüssel als HMAC-Geheimnis.
Schutz: Binden Sie den Schlüssel mit der Konfiguration an den Algorithmus; Symmetrische/asymmetrische Anbieter nicht in einem „Kind“ mischen.

6. 3 Schlüsselinjektion ('kid/jku/x5u')

• 'jku' zeigt auf ein von einem Angreifer kontrolliertes JWKS (rutscht seinen Schlüssel ab).
• „x5u “/„ x5c“ Missbrauch externer Zertifikate.
• 'kid' mit Pfad-Injektion/SQL (' "../../privkey. pem "'oder' 'OR 1 = 1 --'').

• Ignorieren Sie gelöschte' jku/x5u 'oder filtern Sie nach strengen allow-list Domains.
• 'kid' nur als Schlüssel im lokalen Verzeichnis (Tabelle/Cache) verwenden, keine Dateipfade/SQL-Verkettungen.
• JWKS Versand mit vertrauenswürdigen URLs, kurze TTL, Signatur/Pinning-Kanal.

6. 4 Schwache Geheimnisse der HS256 (Brute Force)

Fazit: HMAC-secret short/leck → signature replacement.
Schutz: Verwenden Sie Asymmetrie (RS/ES/PS) oder Geheimlänge ≥ 256 Bit, Geheimnisse - nur in KMS.

6. 5 Fehlende/nichtvalide Stempel

Es gibt kein 'aud'/' iss '/' exp' → das Token ist dienstübergreifend nutzbar oder unendlich.
Zu lange „exp“ → das Risiko einer Kompromittierung.
Schutz: Verlangen Sie einen vollständigen Satz von Stigmen, 'exp' kurz, 'nbf '/' iat' mit 'clock _ skew' validieren.

6. 6 Wiederholung und Token-Diebstahl

Unterm Strich: Abfangen/Wiederholen des Tokens (Leck in den Protokollen, XSS, MitM ohne TLS).

• TLS везде, `Secure`+`HttpOnly` cookie, SameSite=Lax/Strict.
• DPoP/PoP (Token Binding to Client Key) und/oder mTLS für Partner.
• Kurze' exp', refresh-rotation, device-binding.

6. 7 Leckagen über XSS/Speicher

Fazit: Die Speicherung von JWT in 'localStorage '/' sessionStorage' → JS zur Verfügung.
Schutz: Speichern Sie Access-Token in einem HttpOnly-Cookie (sofern ein Cookie-Modell möglich ist) + strengen CSP/Trusted Types.
Für SPA ohne Cookies - isolieren Sie das Token im Speicher, leben Sie minimal, schützen Sie sich vor XSS.

6. 8 CSRF

Unterm Strich: Bei Cookie-Sitzungen Anfragen von einer fremden Webseite.
Schutz: SameSite, Anti-CSRF-Token (double submit), 'Origin/Referer' -Check, Fetch-Metadata-Filter.

6. 9 Oversize/Größenmissbrauch

Unterm Strich: riesige Payload/Headlines, DoS auf Parsing.
Schutz: Header/Body Sizing Limits, Early-Reject 431/413, Fixsatz von Stigmen.

6. 10 Substitution 'typ '/' cty'

Die Essenz: Typenverwirrung ('typ:' JWT'), verschachtelte JOSE-Objekte.
Schutz: Ignorieren Sie' typ/cty 'für Sicherheit, verlassen Sie sich auf feste Algorithmen und Stigma-Muster.

7) Speicherung und Übertragung von Token

7. 1 Server-APIs (Machine-to-Machine)

mTLS/HMAC, vorzugsweise Asymmetrie für JWT, Kanäle - über Mesh.
Schlüsselspeicher - KMS/HSM, Rotation nach Zeitplan, JWKS mit Überlappung.

7. 2 Browser-Clients

HttpOnly Secure Cookie для access/refresh; kurze TTL; update - via „silent refresh“ mit 'SameSite = None' nur unter HTTPS.
Strenge CSP, Trusted Types, schützen vor XSS; für SPA - wenn möglich, speichern Sie das Token nicht auf der Festplatte.

8) JWKS, Rotation und Rückruf

JWKS wird vom Autorisierenden veröffentlicht; Verbraucher Caching für 5-15 Minuten.
Rotationsplan: Fügen Sie ein neues' Kid' hinzu → beginnen Sie mit der Unterzeichnung → entfernen Sie nach N Tagen das alte aus JWKS → Purge.
Widerruf: Listen "jti/sid' c TTL; im Falle eines Vorfalls vorübergehend „exp“ und höhere Abmeldung (invalid refresh) kürzen.

9) Multi-tenant und Datenminimierung

Fügen Sie' tenant '/' org 'nur dann in das Token ein, wenn es für die Architektur erforderlich ist; Andernfalls ziehen Sie Attribute von PDP nach 'sub'.
Keine PII; minimaler Satz von Stigmen → geringeres Risiko von Lecks und Korrelation.

10) Praktische Validierungs-Checkliste (Ressourcenserver)

• Parsim nur nach Überprüfung der Signatur und der zugrunde liegenden Größenlimits.
• 'alg' aus der Konfiguration; das Unerwartete abzulehnen.
• Überprüfen Sie' iss' ∧ 'aud' ∧' exp '∧' nbf '∧' iat'(mit 'clock _ skew').
• Überprüfen Sie' kid' auf lokales Verzeichnis/JWKS (kurze TTL).
• Externe Zeiger filtern/normalisieren ('jku/x5u' - nur allow-list).
• Begrenzen Sie die Länge/Zusammensetzung der Stempel (Schema).
• Objektberechtigung auf Ressource anwenden (BOLA-first).
• 'kid',' sub', 'aud',' iss', 'jti', 'exp', 'tenant', 'trace _ id' (ohne PII) protokollieren.
• Metriken für Signaturfehler, Verzögerungen, Rotationsaudits.

11) Beispiele für sichere Richtlinien (Pseudo)

11. 1 Konfiguration der Erwartungen des Algorithmus

yaml jwt:
expected_issuer: "https://auth. example. com"
expected_audience: ["wallet-service"]
allowed_algs: ["ES256"] # fix the jwks_url: "https ://auth. example. com/.well-known/jwks. json"
jwks_cache_ttl: 600s clock_skew: 60s required_claims: ["iss","aud","sub","exp","iat"]

11. 2 Ablehnung von gelöschten 'jku/x5u'

yaml reject_untrusted_key_sources: true allowed_jku_hosts: ["auth. example. com"] # if absolutely necessary

11. 3 Beispiel für eine Feedback-Liste (Redis)

pseudo if redis. exists("revoke:jti:" + jti) then deny()
if now() > exp then deny()

12) Beobachtbarkeit und Forensik

Метрики: `jwt_verify_fail_total{reason}`, `jwt_expired_total`, `jwks_refresh_total`, доля `kid`.
Protokolle (strukturiert): 'iss/aud/sub/kid/jti/exp/tenant/trace _ id', Fehlerursache.
Dashboards: „Auslaufen in Kürze“, Anstieg der Validierungsfehler, Verteilung auf Regionen/Kunden.
Alertas: Wachstum von 'verify _ fail' (Signatur/Algorithmus), JWKS-Fehler, Anteil abgelaufener Token.

13) Antipatterns

Vertrauen Sie' alg 'vom Token; „none“ beibehalten.
Langlebige Access-Token und keine Refresh-Rotation.
HS256 mit kurzem Geheimnis/Geheimnis in ENV ohne KMS.
Akzeptieren Sie' jku/x5u 'von jeder Domain; JWKS ohne allow-list dynamisch laden.
Setzen Sie PII/Geheimnisse in payload JWS.
Speichern Sie Token in 'localStorage', wenn XSS-Risiken bestehen.
Validierungsfehler übertönen (200 mit „soft error“ zurückgeben).
Keine BOLA-Kontrollen und nur auf 'scope/role' angewiesen.

14) Spezifität von iGaming/Finanzen

Kleims: 'kyc _ level', 'risk _ tier', 'tenant', streng 'aud'.
Kurze TTLs für Write-Operationen (Ein-/Auszahlungen), PoP/DPoP oder mTLS für kritische Routen.
Regulatorisches Audit: unveränderliche Log-Eingänge/Fehler, Speicherung der Protokolle innerhalb der Grenzen der Region.
Partner/PSP haben separate Schlüssel/' aud', Per-Tenant-Schlüssel und separate JWKS.

15) Checkliste Prod-Ready

• Starre Allow-Liste der Algorithmen; 'none' ist verboten.
• „iss/aud/exp/nbf/iat/jti“ werden überprüft; kurz „exp“.
• JWKS mit Überlappung, kurze Cache-TTL; Überwachung der Anteile von "kid'.
• Refresh — rotate-on-use; "jti/sid' -Listen mit TTL; Playbook der Bewertungen.
• PoP/DPoP oder mTLS auf kritischen Strecken.
• HttpOnly-Cookies für Browser, CSP/Trusted Types vs. XSS; CSRF-Schutz.
• Keine PII in payload; Mindestsatz von Marken.
• Metriken/Protokolle für Validierung und Fehler; alert JWKS/verify_fail.
• Negative Szenariotests: RS→HS swap, 'kid' -Injektionen, 'jku' spoofing, oversize, clock-skew.

16) TL; DR

Fixieren Sie den Algorithmus und die Schlüssel auf der Serverseite, vertrauen Sie nicht 'alg' vom Token, fordern Sie' iss/aud/exp/nbf/iat/jti'. Rotieren Sie Schlüssel durch JWKS mit Überlappung, halten Sie Token kurzlebig und aktualisieren Sie sie einmalig. Token sicher aufbewahren (HttpOnly-Cookie für das Web), Stempel minimieren, keine PII setzen. Schließen Sie' jku/x5u/kid' -Vektoren, vermeiden Sie HS256 mit schwachen Geheimnissen, fügen Sie PoP/DPoP oder mTLS auf kritischen Pfaden hinzu und führen Sie immer BOLA-Überprüfungen auf Ressourcenebene durch.