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 Single-Page Applications verhindern mit DPoP Alexander Schwartz | Keycloak Maintainer enterJS (Mannheim, DE) | 2026-06-16
2. Evolution von Single Sign On und Delegation SAM L 2.0 (SSO m it XM L) 2005
3. Evolution von Single Sign On und Delegation SAM L 2.0 (SSO m it XM L) OAuth 1.0 (zu kom plex) 2005 2007 OAuth 2.0 (Ressourcenzugriff) 2012 2014 OpenID Connect (Identität)
4. Token Flow mit Single Page Applications Browser mit SPA Resource Server Identity Provider (IdP) Login, Token Refresh API Aufruf mit Access Token Token prüfen
5. Evolution von Single Sign On und Delegation SAM L 2.0 (SSO m it XM L) OAuth 1.0 (zu kom plex) 2005 2007 OAuth 2.0 (Ressourcenzugriff) 2012 2014 OpenID Connect (Identität) 2021 FAPI 1.0 (Open Banking) 2025 Best Current Practice for OAuth 2.0 2025 FAPI 2.0 (Finance, E-Health, … ) OAuth 2.1 (the secure parts) 2026?
6. 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 Sicherheitsannahmen FAPI 2.0 https://openid.net/specs/fapi-attacker-model-2_0-final.html
7. A1: Web-basierte Angriffe: Kann URLs aufrufen, User auf links klicken lassen, aber keine Verschlüsselung brechen. A2: Abhören des Netzwerks, kann aber keine Verschlüsselung brechen A3a:Kann Authorization Requests im Browser mitlesen. A5: Kann Proxy- und Resource-Logs lesen, aber keine Antworten. … Attacker Models FAPI 2.0 https://openid.net/specs/fapi-attacker-model-2_0-final.html 😈 Resource Proxy Browser IdP
8. • 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. 🔒 Transportschicht absichern https://openid.net/specs/fapi-security-profile-2_0-final.html Clients & Browser Server TLS
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. • 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) Benutze OAuth Best Practices https://openid.net/specs/fapi-security-profile-2_0-final.html Clients & Browser Server TLS 🔒
12. • 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) Benutze OAuth Best Practices für SPAs https://openid.net/specs/fapi-security-profile-2_0-final.html Clients & Browser Server TLS 🔒
13. Mit PKCE den Authorization Code absichern Client IdP Mit Proof Key for Code Exchange kann niemand anderes den Authorization Code verwenden: 1. Schicke eine Code Challenge zu Beginn des Authorization Code Flow 2. Der Browser leitet sie an den IdP weiter 3. Schicke den Code Verifier als Teil des Code-to-Token Exchange Browser 2 1 3
14. Mit Demonstrating Proof-of-Possession (DPoP) sichert ein Ephemeral Client Key Pair alle Schritte ab: 1. Erstelle ein Ephemeral Key Pair (bei SPAs mit dem WebCrypto API) 2. Nutze des Authorization Code Flow mit PKCE oder DPoP 3. 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 4. Nutze DPoP für alle weiteren Refresh Tokens 5. Optional: Nutze DPoP for APIs (mit “Authorization: DPoP …”) Sender Constrained Tokens: DPoP Client APIs IdP 5 2,3,4 https://www.keycloak.org/nightly/securing-apps/dpop
15. HTTP Methode, URI, DPoP Proof, Access Token und ggf. Nonce müssen zusammenpassen! Sender Constrained Tokens: DPoP 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 ⭐ 35k GitHub stars
17. Keycloak unterstützt verschiedene Standards OpenID Connect, OAuth, SAML, … 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. 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
19. Case Studies https://www.keycloak.org/case-studies Hitachi Ltd. used Keycloak to make financial grade security easier OpenTalk achieves versatile and compliant user authentication with Keycloak BRZ migrated the Austrian Business Service Portal with 2M+ users to Keycloak
20. • Keycloak https://www.keycloak.org/ • Case Studies https://www.keycloak.org/case-studies • KeycloakCon @ KubeCon Japan https://events.linuxfoundation.org/kubecon-cloudnativecon-japan/ • KeyConf Prague https://keyconf.dev/ Links Folien:
21. Alexander Schwartz Keycloak Maintainer alexander.schwartz@gmx.net https://www.ahus1.de @ahus1.de @ahus1@fosstodon.org Kontakt