Replay-resistente JWT-Sessions

Bearer-JWTs sind einfach, weil Besitz genügt. Genau das ist das Problem. Wenn ein Angreifer das Token aus Logs, Malware, einem Proxy, einer Browser-Erweiterung oder einem eingefügten Support-Ticket bekommt, kann die API meist nicht zwischen Angreifer und Benutzer unterscheiden. Replay-Resistenz soll diese Lücke verkleinern, ohne so zu tun, als wäre ein JWT plötzlich eine hardwaregebundene Credential.

Mit Leak-Pfaden beginnen

Bevor Mechanismen dazukommen, kartiere, wohin Tokens reisen. Authorization-Header laufen durch Load Balancer, Application Logs, APM-Agenten, Error Reporter, Reverse Proxies und manchmal kundengesteuerte Integrationen. Browser-Tokens können in Session-Replay-Tools oder kopierten curl-Befehlen auftauchen. Mobile Tokens landen in Crash Reports. Jedes Anti-Replay-Design scheitert, wenn die Organisation Bearer Tokens weiter an Orte kopiert, die Angreifer lesen können.

Kurze Lebensdauer hilft, aber erst nachdem Leaks reduziert wurden. Ein Fünf-Minuten-Token in ausführlichen Logs ist für fünf Minuten trotzdem ein Remote-Zugang zur API, wenn es breite Rechte trägt. Scope und Audience sind genauso wichtig wie Dauer.

jti und serverseitiger Session-State

jti gibt jedem Token eine Kennung. Nützlich wird sie, wenn der Verifier diese Kennung gegen Session-State, eine Revocation-Liste oder eine Rotationskette prüfen kann. Ohne Lookup ist jti nur ein Etikett. Mit Lookup gewinnt man Session-Semantik zurück: ein Gerät widerrufen, Wiederverwendung nach Refresh-Rotation erkennen und Tokens nach Credential-Reset invalidieren.

Replay-Muster erkennen

Blockiere nicht allein wegen einer geänderten IP. Mobilnetze und Unternehmens-VPNs machen das laut. Kombiniere Signale: unmögliche Reise, Wechsel der User-Agent-Familie, Gerätewechsel, Wiederverwendung eines alten Refresh Tokens und Zugriff aus einer Region, die das Konto nie genutzt hat. Logge genug zur Untersuchung, aber keine vollständigen Tokens. Hash jti oder Session-IDs, wenn Logs die Vertrauensgrenze verlassen.

Stärkere Optionen

Proof-of-Possession-Ansätze binden das Token an einen Schlüssel, den der Client pro Request verwenden muss. DPoP und mTLS sind Beispiele, bringen aber operativen Aufwand. Sie passen zu hochwertigen APIs, Maschinenclients, Partnerintegrationen und administrativen Oberflächen. Für normale Browser-Sessions sind gut gemanagte Refresh-Rotation, HttpOnly-Cookies, enge Scopes und schnelle Revocation oft der bessere Kompromiss.

Praktisches Design

Behandle Replay-Resistenz als Schichten. Reduziere Token-Exposition, halte Access Tokens kurz, rotiere Refresh Tokens, speichere Session-State serverseitig und alarme bei Wiederverwendungssignalen. Ein JWT kann die Request-Credential bleiben, während das Session-Modell außerhalb lebt. Diese Trennung macht oft den Unterschied zwischen "einmal gestohlen, überall gültig" und "einmal gestohlen, schnell eingedämmt".