Token-Diebstahl in OAuth 2.0 Single-Page Applications verhindern mit DPoP

OAuth 2.0 verwendet Access Tokens, um den Zugriff auf geschützte Ressourcen zu gewähren. Bei Single-Page-Anwendungen (SPAs) werden diese als Bearer-Tokens über HTTP-Header vom Browser an den Server übertragen.

Obwohl die Tokens während der Übertragung durch TLS geschützt sind, können sie möglicherweise aus einem Browser gestohlen, auf einem Proxy abgefangen oder von einem bösartigen oder unsicheren Server missbraucht werden. Der Standard OAuth 2.0 Demonstrating Proof-of-Possession (DPoP) sorgt hier vor, indem es im Client – beispielsweise Ihrer SPA – ein zusätzliches Schlüsselpaar nutzt. Damit kann dieser einen Nachweis erzeugen, sodass niemand anderes die Tokens verwenden kann. DPoP ist Teil des FAPI 2.0 Security Profile der OpenID Foundation. Dies enthält Best Practices zum Schutz von APIs für sensible Daten zum Beispiel aus den Bereichen Finanzen, E-Health und E-Government.

In diesem Vortrag erläutere ich die Konzepte und zeige anhand von Demos, wie dies mit Keycloak und anderen Open-Source-Komponenten implementiert werden kann. Außerdem stelle ich die aktuellen Herausforderungen, Grenzen und Alternativen des Ansatzes dar.

Transcript

1. Token-Diebstahl in OAuth 2.0 verhindern mit DPoP Alexander Schwartz | Keycloak Maintainer NetKnights (Kassel, DE) | 2026-09-23
2. 20 05 SA M L 2. 0 (S SO m it X M L) Evolution von Single Sign On und Delegation
3. 14 20 12 20 07 20 05 20 ct ne rif f) t) en titä (Id ce nz ug L) x) ple ko m M it X m es so ur (R Co n 0 2. ID en Op h u (z SO (S 0 1. 2. 0 h ut ut OA OA L M SA Evolution von Single Sign On und Delegation
4. Token Flow mit Single Page Applications Browser mit SPA Login, Token Refresh Identity Provider (IdP) API Aufruf mit Access Token Token prüfen Resource Server
5. ? 26 20 25 20 25 20 21 20 14 20 12 20 07 20 05 20 h I2 ut OA FA P (O fo ) e se cu r ) rts pa ,… ) lth th Au rO -H ea ,E e tic ac nc e e (th ina (F 1 2. .0 Pr ing nk rif f) t) en titä (Id Ba ct pe n nt rre .0 Cu I1 st Be FA P ne ce nz ug L) ko m ple x) M it X m es so ur (R Co n 0 2. ID h u (z SO (S 0 1. 2. 0 h en Op ut OA ut OA L M SA 0 2. Evolution von Single Sign On und Delegation
6. Sicherheits-Annahmen FAPI 2.0 Angreifer-Persona: Was ist sicher, was kann kompromittiert werden. Was als sicher angenommen wird und damit out-of-scope ist: 🔒 Transport Layer Security (TLS) 🔑 Verteilte öffentliche Schlüssel (JWKS) 💻 Browser und andere Endpunkte 🪪 Identitäten und Session-Management https://openid.net/specs/fapi-attacker-model-2_0-final.html
7. Attacker Models FAPI 2.0 �� A1: Web-basierte Angriffe: Kann URLs aufrufen, User auf links klicken lassen, aber keine Verschlüsselung brechen. Browser A2: Abhören des Netzwerks, kann aber keine Verschlüsselung brechen 😈 Proxy A3a:Kann Authorization Requests im Browser mitlesen. A5: Kann Proxy- und Resource-Logs lesen, aber keine Antworten. Resource IdP … https://openid.net/specs/fapi-attacker-model-2_0-final.html
8. Transportschicht absichern • • • • • • TLS 1.2+ TLS Zertifikate prüfen DNSSEC Sichere TLS Algorithmen verwenden HSTS gegen Downgrade-Attacken … TL;DR: Best Practices verwenden, um die out-of-scope Annahmen abzusichern. Clients & Browser 🔒 TLS Server https://openid.net/specs/fapi-security-profile-2_0-final.html
9. Einfacher OAuth 2.0 Authorization Code Flow GET authorization_endpoint + ?redirect_uri=...&prompt=login..." GET redirect_uri "?...session_state=...code=..." POST code and other parameters to token_endpoint response with ID token, access token, refresh token, ...
10. Token-Refresh und API-Auruf POST refresh_token to token endpoint response with ID token, access token, refresh token, ... Call API endpoint with access token as “Authorization: Bearer ..." header Receiving API response
11. Benutze OAuth Best Practices • • • • • • TLS für alle Endpunkte Kein Resource Owner Password Credentials Grant Kein Implicit Grant Nur ein Audience in den Tokens Keine Wildcards in Redirect URIs Private Key JWT Client Authentication (= no public clients) • • • Pushed Authorization Requests (PAR) PKCE with S256 Sender Constrained Tokens (mTLS or DPoP) Clients & Browser 🔒 TLS Server https://openid.net/specs/fapi-security-profile-2_0-final.html
12. Benutze OAuth Best Practices für SPAs • • • • • • TLS für alle Endpunkte Kein Resource Owner Password Credentials Grant Kein Implicit Grant Nur ein Audience in den Tokens Keine Wildcards in Redirect URIs Private Key JWT Client Authentication (= no public clients) • • • Pushed Authorization Requests (PAR) PKCE with S256 Sender Constrained Tokens (mTLS or DPoP) Clients & Browser 🔒 TLS Server https://openid.net/specs/fapi-security-profile-2_0-final.html
13. Mit PKCE den Authorization Code absichern Mit Proof Key for Code Exchange kann niemand anderes den Authorization Code verwenden: 1. 2. 3. Schicke eine Code Challenge zu Beginn des Authorization Code Flow Der Browser leitet sie an den IdP weiter Schicke den Code Verifier als Teil des Code-to-Token Exchange Browser 1 Client 2 IdP 3
14. Sender Constrained Tokens: DPoP Mit Demonstrating Proof-of-Possession (DPoP) sichert ein Ephemeral Client Key Pair alle Schritte ab: 1. 2. 3. 4. 5. Erstelle ein Ephemeral Key Pair (bei SPAs mit dem WebCrypto API) Nutze des Authorization Code Flow mit PKCE oder DPoP Nutze das DPoP Schlüsselpaar für den Code-to-Token Flow um das Access Token (alle Clients) und das Refresh Token (Public Client) an das Schlüsselpaar zu binden und Missbrauch zu verhindern APIs Nutze DPoP für alle weiteren Refresh Tokens 5 Optional: Nutze DPoP for APIs (mit “Authorization: DPoP …”) Client https://www.keycloak.org/nightly/securing-apps/dpop IdP 2,3,4
15. Sender Constrained Tokens: DPoP HTTP Methode, URI, DPoP Proof, Access Token und ggf. Nonce müssen zusammenpassen! GET /protected-resource HTTP/1.1 Authorization: DPoP <Access-Token> DPoP: <DPoP-Proof> HTTP/1.1 401 Unauthorized DPoP-Nonce: <Nonce> { "error": "use_dpop_nonce", ... GET /protected-resource HTTP/1.1 Authorization: DPoP <Access-Token> DPoP: <DPoP-Proof-with-Nonce> } HTTP/1.1 200 OK ...
16. Keycloak ist ein Open Source Identity und Access Management System 🎂 First Commit 2013-07-02 🏆 Cloud Native Computing Foundation Incubating project since April 2023 📜 Apache License, Version 2.0 ⭐ 37k GitHub stars
17. Keycloak unterstützt verschiedene Standards OpenID Connect, OAuth, SAML, SCIM, Shared Signals, … Inklusive: • • • FAPI 2.0 Security Profile OAuth DPoP (Demonstrating Proof-of-Possession) The OAuth 2.1 Authorization Framework (Draft) Demo: Let’s enforce DPoP! https://github.com/ahus1/dpop-demo
18. Release-Highlights 2026 für Nutzer, Admins und KI 🔑 Token Exchange, Dynamic Scopes 🛂 Zero-Trust Ephemeral Credentials für Maschinen ⚙ User Lifecycle Management mit Workflows 🛑 Shared Signals Framework 🗂 SCIM für Provisionierung von Nutzern ♻ Split-Brain Detection und Rolling Updates 💫 Stateless Keycloak für Multi-Cluster Setups 🗄 Datenbank-Template für CloudNativePG
19. Bibliotheken, die helfen • • • • mod_auth_openidc / OAuth 2 and OpenID Connect for Apache 2.x httpd server Supports FAPI 2.x (including DPoP) https://github.com/OpenIDC/mod_auth_openidc openid-client / OAuth 2 and OpenID Connect Client API for JavaScript Runtimes https://github.com/panva/openid-client Certified for FAPI 2.0 (including DPoP) Nimbus OAuth SDK / Framework-agnostic OAuth 2 and OpenID Connect for Java https://connect2id.com/products/nimbus-oauth-openid-connect-sdk Quarkus / OIDC, OAuth und DPoP https://quarkus.io/guides/security-oidc-bearer-token-authentication
20. Case Studies Hitachi Ltd. nutzt Keycloak für API-Gateways bei Banken OpenTalk nutzt flexible NutzerAuthentifikation mit Keycloak BRZ migrierte das Austrian Business Service Portal mit 2M+ Nutzern nach Keycloak https://www.keycloak.org/case-studies
21. Links • Keycloak https://www.keycloak.org/ https://www.keycloak.org/securing-apps/dpop • Konferenzen KeyConf, Prague / 2026-10-08 🔗 KeycloakCon @ KubeCon EU, Barcelona / 2027-03-15 🔗 Keycloak DevDay, Darmstadt / 2027-04-08…09 🔗 Folien:
22. Kontakt Alexander Schwartz Keycloak Maintainer alexander.schwartz@gmx.net https://www.ahus1.de @ahus1.de @ahus1@fosstodon.org