2. Objectives (Ziele)
2. Objectives (Ziele)
Das Hauptziel von DPoP besteht darin, die unbefugte oder illegitime Verwendung von durchgesickerten oder gestohlenen Zugriffstoken durch Unbefugte zu verhindern, indem ein Token bei der Ausstellung an einen öffentlichen Schlüssel gebunden wird und der Client bei der Verwendung des Tokens den Besitz des entsprechenden privaten Schlüssels nachweisen muss. Dies beschränkt den legitimen Absender des Tokens darauf, nur die Partei zu sein, die den privaten Schlüssel besitzt, und gibt dem Server, der das Token empfängt, die Gewissheit, dass der Absender rechtmäßig zur Verwendung berechtigt ist.
Über DPoP an den Absender gebundene Zugriffstoken stehen somit im Gegensatz zu typischen Bearer-Token, die von jeder Partei verwendet werden können, die im Besitz eines solchen Tokens ist. Während im Allgemeinen Sicherheitsvorkehrungen getroffen werden, um die unbeabsichtigte Offenlegung von Bearer-Token zu verhindern, sind aufgrund von Schwachstellen und Implementierungsproblemen in anderen Schichten des Protokoll- oder Software-Stacks unvorhergesehene Leckagevektoren aufgetreten (z. B. Compression Ratio Info-leak Made Easy (CRIME) [CRIME], Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) [BREACH], Heartbleed [Heartbleed] und Cloudflare-Parser-Bug [Cloudbleed]). Auch OAuth-Implementierungen selbst haben zahlreiche öffentlich bekannt gewordene Token-Diebstahlsangriffe erlebt ([GitHub.Tokens] ist nur ein bemerkenswertes Beispiel). DPoP bietet einen allgemeinen Defense-in-Depth-Mechanismus zum Schutz vor den Folgen solcher unbeabsichtigten Token-Lecks. DPoP ist jedoch kein Ersatz für einen sicheren Transport und muss immer in Verbindung mit HTTPS verwendet werden.
Die Natur typischer OAuth-Protokollinteraktionen erfordert, dass der Client das Zugriffstoken an die geschützte Ressource weitergibt, auf die er zugreift. Das Angreifermodell in [SECURITY-TOPICS] beschreibt den Fall, dass die geschützte Ressource gefälscht, böswillig oder kompromittiert ist und das empfangene Token bei anderen geschützten Ressourcen verwendet, um unbefugten Zugriff zu erhalten. Audience-beschränkte (Audience-restricted) Zugriffstoken (z. B. unter Verwendung des aud-Claims eines JWT [RFC7519]) können einen solchen Missbrauch verhindern. In der Praxis hat sich dies jedoch für viele Bereitstellungen als zu belastend erwiesen (trotz Erweiterungen wie [RFC8707]). Die Senderbindung von Zugriffstoken ist ein robusterer und direkterer Mechanismus zur Verhinderung der Wiederverwendung solcher Token an verschiedenen Endpunkten, wobei DPoP ein praktikables Mittel auf Anwendungsebene ist.
Browserbasierte OAuth-Clients bringen aufgrund des potenziellen Risikos von Cross-Site Scripting (XSS) zusätzliche Überlegungen zum Schutz von Token mit sich. Der direkteste XSS-basierte Angriff besteht darin, dass der Angreifer das Token stiehlt und es völlig unabhängig vom legitimen Client verwendet. Gestohlene Zugriffstoken werden verwendet, um auf geschützte Ressourcen zuzugreifen, und gestohlene Refresh-Token werden verwendet, um neue Zugriffstoken zu erhalten. Wenn der private Schlüssel so gespeichert wird, dass er nicht exportiert werden kann (wie durch [W3C.WebCryptoAPI] ermöglicht), macht DPoP gestohlene Token für sich allein nutzlos.
Eine XSS-Schwachstelle ermöglicht es einem Angreifer auch, Code im Kontext der browserbasierten Client-Anwendung auszuführen und das Token indirekt über den Client böswillig zu verwenden. Dieser Ausführungskontext hat Zugriff auf Signaturschlüssel; daher können DPoP-Proofs zur Verwendung in Kombination mit dem Token erstellt werden. Es wird angenommen, dass es auf dieser Anwendungsebene keine praktikable Verteidigung gegen diese Bedrohung gibt, abgesehen von der generellen Verhinderung von XSS; daher wird dies als außerhalb des Geltungsbereichs von DPoP betrachtet.
Böswilliger XSS-Code, der im Kontext der browserbasierten Client-Anwendung ausgeführt wird, kann auch DPoP-Proofs mit zukünftigen Zeitstempelwerten erstellen und diese zusammen mit Token exfiltrieren. Diese gestohlenen Artefakte können dann später unabhängig von der Client-Anwendung für den Zugriff auf geschützte Ressourcen verwendet werden. Um dies zu verhindern, kann ein Server optional verlangen, dass der Client einen vom Server gewählten Wert (eine Nonce) in den Proof aufnimmt, der für den Angreifer unvorhersehbar ist. Ohne eine optionale Nonce wird die Auswirkung vorberechneter DPoP-Proofs durch die Bindung des Proofs an das Zugriffstoken für den Zugriff auf geschützte Ressourcen begrenzt. Da es praktisch nicht möglich ist, einen Proof zu erstellen, der ein noch nicht existierendes Zugriffstoken abdeckt, ist ein Zugriffstoken, das mit einem gestohlenen Refresh-Token und einem vorberechneten Proof erhalten wurde, nicht verwendbar.
Weitere Sicherheitsüberlegungen werden in Abschnitt 11 behandelt.