Gefahren durch gestohlene Access-Tokens
In modernen Authentifizierungs- und Autorisierungsmechanismen spielen Access-Tokens eine zentrale Rolle. Sie ermöglichen es Clients, im Namen eines Benutzers auf geschützte Ressourcen zuzugreifen, ohne eine Session zu benötigen oder ständig Zugangsdaten übertragen zu müssen.
Doch was passiert, wenn ein Access-Token in die falschen Hände gerät? Die Konsequenzen können verheerend sein: Identitätsdiebstahl, Datenexfiltration und unautorisierter Zugriff auf sensible Systeme.
Risiken gestohlener Access-Tokens
Access-Tokens sind oft als sogenannte "Bearer Tokens" implementiert. Das bedeutet, dass jeder, der im Besitz eines gültigen Tokens ist, damit Anfragen an die geschützte Ressource stellen kann. Wird ein solches Token von einem Angreifer abgefangen – beispielsweise durch Man-in-the-Middle-Angriffe, Logging in unsicheren Umgebungen oder Cross-Site-Scripting (XSS) – kann es für unautorisierte Zugriffe missbraucht werden. Zwar haben Access-Tokens typischerweise eine begrenzte Lebensdauer, innerhalb dieses Zeitraums können Angreifer allerdings oft weitgehend ungehindert agieren.
Schutzmaßnahmen: Demonstrating Proof of Possession (DPoP) und MTLS
Um das Risiko von gestohlenen Tokens zu minimieren, gibt es Mechanismen, die verhindern, dass ein reines "Haben" des Tokens ausreicht. Zwei vielversprechende Ansätze sind Demonstrating Proof of Possession (DPoP, RFC9449) und Mutual TLS (MTLS, RFC8705).
Demonstrating Proof of Possession (DPoP)
DPoP erweitert das OAuth-Framework um eine Schutzschicht, indem es von Clients verlangt, kryptografisch nachzuweisen, dass sie tatsächlich rechtmäßige Besitzer des Tokens sind. Dies geschieht, indem ein DPoP-Beweis (eine signierte JWT) in jede Anfrage eingebettet wird. Da diese Signatur an spezifische Merkmale der Anfrage gebunden ist, können abgefangene Tokens nicht einfach wiederverwendet werden.
Mutual TLS (MTLS)
MTLS nutzt Client-Zertifikate, um eine sichere und beidseitig authentifizierte Verbindung zwischen Client und Server aufzubauen. Durch diese Methode werden Access-Tokens an ein bestimmtes Zertifikat gebunden, sodass nur der rechtmäßige Client sie verwenden kann. Selbst wenn ein Angreifer ein Token stiehlt, kann er es nicht ohne das zugehörige Zertifikat nutzen.
Allerdings bringt MTLS einige Herausforderungen mit sich: Die Implementierung erfordert eine Public Key Infrastructure (PKI), um Client-Zertifikate auszustellen, zu verwalten und gegebenenfalls zu widerrufen. Dies kann mit erheblichem administrativem Aufwand verbunden sein. Zudem kann MTLS in großen verteilten Systemen schwer skalierbar sein, da jeder Client ein eigenes Zertifikat benötigt. Auch die eingeschränkte Kompatibilität kann ein Problem darstellen: Nicht alle Webbrowser und mobilen Anwendungen unterstützen Client-Zertifikate für MTLS vollumfänglich. Dies kann zusätzliche Konfigurationen erfordern und die Nutzung erschweren.
DPoP stellt sich daher oft als die flexiblere Alternative dar, die einfacher zu implementieren ist.
Anforderungen aus dem FAPI 2.0 Security Profile
Das Financial-grade API (FAPI) 2.0 Security Profile legt besonderen Wert auf die Absicherung von Access-Tokens und schreibt vor, dass Clients sogenannte sender-constrained Access-Tokens unterstützen müssen.
Dabei wird explizit eine der beiden oben genannten Methoden gefordert:
-
MTLS gemäß RFC8705
-
DPoP gemäß RFC9449
Damit wird sichergestellt, dass gestohlene Tokens für Angreifer nutzlos sind, da sie nur vom vorgesehenen Client genutzt werden können.
Ausblick
In den folgenden Artikeln werden wir uns der konkreten Umsetzung in anspruchsvollen Umgebungen widmen.
Wir betrachten die Integration von DPoP in Authorization Servern wie Keycloak, zeigen die Implementierung in Backend-Anwendungen mit Spring Boot und erläutern, wie browser-basierte Frontends auf Basis von Angular oder Vue.js sicher mit diesen Mechanismen arbeiten können.
Fazit
Gestohlene Access-Tokens stellen ein erhebliches Sicherheitsrisiko dar. Unternehmen und Entwickler sollten sich bewusst sein, dass klassische Bearer Tokens ohne zusätzliche Schutzmaßnahmen leicht missbraucht werden können. Durch Mechanismen wie DPoP und MTLS lässt sich das Risiko erheblich reduzieren. Wer auf FAPI 2.0 setzt, muss ohnehin eine dieser Methoden implementieren – eine gute Praxis für alle sicherheitskritischen Anwendungen.
Zu den Themen Keycloak, Spring Security, Angular und Vue bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:
Vor der Inbetriebnahme von sicherheitskritischen Komponenten wie Keycloak, sollte sichergestellt sein, dass das System tatsächlich bereit für den produktiven Einsatz ist und, dass alle wesentlichen Punkte bei Konfiguration, Integration und Betriebsprozessen berücksichtigt wurden. Hierbei hilft unser Production Readiness Review für Keycloak.
Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.