OAuth 2.0 gilt seit seiner Etablierung im Jahr 2012 als eine der zentralen Technologien für die autorisierte Zugriffsverwaltung im Internet. Doch der rasante Fortschritt in Anwendungen, Angriffsmethoden und technischen Rahmenbedingungen macht es zwingend notwendig, Sicherheitskonzepte kontinuierlich zu überarbeiten und anzupassen. Im Januar 2025 veröffentlichte die IETF den aktuellen Standard RFC 9700, der die neuesten Best Current Practices für OAuth 2.0 Sicherheit zusammenfasst und reflektiert, wie Entwickler ihre Anwendungen heute optimal schützen können.
Immer mehr Anwendungen setzen auf OAuth 2.0 zur Delegierung von Zugriffsrechten, während OpenID Connect (OIDC) als Erweiterung zur Nutzer-Authentifizierung in unzähligen Login-Szenarien genutzt wird. Besonders die Komplexität der heutigen Ökosysteme, in denen multinationale, multitenante Anwendungen und dynamische Service-Provider-Konstellationen zum Alltag gehören, stellt hohe Anforderungen an die sichere Implementierung. Die neuesten Sicherheitspraktiken adressieren genau diese Herausforderungen und bieten sowohl pragmatische als auch technische Maßnahmen, die Entwickler kennen und umsetzen sollten. Ein grundlegendes Verständnis der beteiligten Parteien – wie Client, Authorization Server und Resource Server – sowie der verwendeten Objekte wie Access Tokens, ID Tokens und Autorisierungscodes ist die Basis, um die empfohlenen Schutzmechanismen richtig einzuordnen und anzuwenden.
Dabei gilt es, zwischen vertraulichen Clients, die in einem sicheren Backend betrieben werden und öffentliche Clients, die auf Endnutzergeräten laufen, klar zu unterscheiden. Browser-basierte Anwendungen und native Apps sind typische Beispiele für öffentliche Clients und benötigen besondere Sicherheitsvorkehrungen, da sie keine Möglichkeit haben, geheime Schlüssel dauerhaft und sicher zu speichern. Ein zentraler Fokus der neuen Best Practices liegt auf dem Schutz von Redirect-Flows. In vielen OAuth- und OIDC-Prozessen werden Nutzer im Browser weitergeleitet, um sich zu authentifizieren, Zugriffsrechte zu vergeben oder den Anmeldestatus zu übermitteln. Diese Umleitungen sind eine typische Angriffsstelle für Angreifer, die versuchen, Autorisierungscodes oder Tokens abzufangen und für sich zu nutzen.
Ein häufiger Fehler besteht darin, Redirect-URIs dynamisch über URL-Parameter zu definieren, was sogenannte offene Redirects ermöglicht. Dies wiederum kann zu unbemerkten Umleitungen auf fremde Domains führen – eine besonders perfide Form der Manipulation. Die exakte Übereinstimmung der Redirect-URIs im Autorisierungsserver ist daher unabdingbar. Wildcard-Muster sollten vermieden werden, da sie potenziell zulassen, dass Angreifer Subdomains etablieren, die vom Server akzeptiert werden. Nur exakt registrierte und überprüfte URIs gewährleisten die notwendige Sicherheit.
Für lokale Entwicklungsumgebungen sind Ausnahmen bei Ports erlaubt, aber auch dort muss sorgfältig konfiguriert werden. Den Schutz gegen Cross Site Request Forgery (CSRF) Angriffen gewährleisten Mechanismen wie die Proof Key for Code Exchange (PKCE) Erweiterung oder das Einbinden eines sogenannten Nonce (eine kryptografisch sichere Zufallszahl) im OIDC Ablauf. PKCE ist mittlerweile ein Standard für öffentliche Clients und verlangt, dass bei jedem Autorisierungsantrag ein eindeutiger Code generiert, mit einer Hashfunktion verarbeitet und serverseitig verifiziert wird. So wird verhindert, dass ein Angreifer einen Autorisierungscode von außen injiziert oder einen legitimen Code wiederverwendet. Die Verwendung des impliziten Grants, bei dem Tokens direkt im Browser an den Client übergeben werden, ist mittlerweile offiziell obsolet und sollte keinesfalls mehr eingesetzt werden.
Tokens in der URL sind anfällig für einfache Diebstahlmethoden und lassen sich von böswilligen Skripten viel zu leicht auslesen. Stattdessen empfiehlt sich ausschließlich das Autorisierungscodeverfahren mit PKCE, um maximale Sicherheit zu gewährleisten. Ein weiteres bedeutendes Thema ist das Verhindern von Token-Replay-Angriffen, bei denen ein erbeutetes Token mehrfach missbräuchlich eingesetzt wird. Access Tokens sollten als so genannte sender constrained Tokens ausgegeben werden. Das bedeutet, dass der Tokenempfänger nachweisen kann, dass der Anfragende tatsächlich der berechtigte Inhaber des Tokens ist.
Methoden wie mutual TLS oder Proof of Possession (demonstrierende Besitznachweise) sorgen dafür, dass einfache Token-Kopien nicht ausreichend sind, um Zugang zu erhalten. Besonders bei Refresh Tokens, die eine lange Lebensdauer haben und zur Verlängerung von Sessions genutzt werden, ist ein solcher Schutz essenziell. Öffentliche Clients sind hier besonders gefährdet, weshalb Sender Constraining bei Refresh Tokens zwingend eingeführt werden sollte. Alternativ ist Refresh Token Rotation eine bewährte Methode: Jedes Mal, wenn ein neues Token ausgestellt wird, wird das alte widerrufen, sodass ein Angreifer nicht kontinuierlich einen gestohlenen Refresh Token benutzen kann. Die Zugriffsrechte, die in Access Tokens gewährt werden, sollten auf ein Minimum beschränkt sein.
Prinzipien wie das Least Privilege-Prinzip helfen dabei, Risiken im Falle einer Kompromittierung zu minimieren. Jedes Access Token sollte eindeutig auf eine bestimmte API oder Ressource ausgestellt sein, was über das Audience-Feld (aud) im Token dokumentiert ist. Ein Resource Server akzeptiert nur Tokens, die für ihn bestimmt sind, und prüft zusätzlich, ob die im Token enthaltenen Rechte – etwa in Form von Scopes oder authorization_details – für die angefragte Aktion ausreichend sind. Eine äußerst unsichere und mittlerweile nicht mehr unterstützte Methode ist die sogenannte Resource Owner Password Credentials (ROPC) Grant, bei der Benutzername und Passwort direkt vom Client zur Token-Anfrage genutzt werden. Diese Praxis öffnet eine Vielzahl an Sicherheitsproblemen, wie die Offenlegung von Passwörtern und scheitert an modernen Anforderungen etwa an Multifaktor-Authentifizierung.
Vor allem die Nutzung von WebCrypto oder WebAuthn ist mit ROPC nicht kompatibel, weswegen diese Grant-Type strikt vermieden werden sollte. Auf Seite der Autorisierungsserver empfehlen die Best Practices eine verpflichtende Client-Authentifizierung. Server sollten vertrauliche Clients eindeutig identifizieren und verifizieren können, idealerweise mittels asymmetrischer Kryptografie, etwa durch private Schlüssel für Signaturen oder Mutual TLS. Dadurch müssen keine symmetrischen Schlüssel gespeichert werden, deren Kompromittierung besonders gefährlich wäre. Weitere wichtige Empfehlungen betreffen unter anderem die konsequente Vermeidung von Cross-Origin Resource Sharing (CORS) an den Ausgabepunkten für Autorisierungsanfragen, da dort über Browser-Umleitungen gearbeitet wird und direkte XMLHttpRequests potenziell Sicherheitslücken öffnen könnten.
Ebenso hilfreich ist die Verwendung von Metadata-Endpunkten, die dynamische Konfigurationsdaten bereitstellen. Dadurch können Clients sich automatisch und fehlerfrei konfigurieren, neue Sicherheitsfeatures nutzen und Schlüsselwechsel reibungslos verarbeiten. Der Einsatz von Ende-zu-Ende Transport Layer Security (TLS) bleibt selbstverständlich ein Grundpfeiler zum Schutz der Kommunikation zwischen Client, Autorisierungsserver und Ressourcenserver. Jede unverschlüsselte HTTP-Verbindung stellt ein zu großes Risiko dar und sollte nach Möglichkeit komplett vermieden werden. Für native Clients, die lokale Loopback-Interfaces verwenden, sind Ausnahmen möglich, dennoch ist selbst dort eine sorgfältige Konfiguration erforderlich.
Das Zusammenspiel dieser Sicherheitsmaßnahmen wird durch eine aktualisierte Angreifermodell-Analyse im RFC 9700 ergänzt. Entwickler erhalten hier umfassende Einblicke in potenzielle Bedrohungen, Angriffsarten und adäquate Gegenmaßnahmen, um ihre Implementierungen kontinuierlich zu stärken. Ein tiefes Verständnis dieses Modells hilft beim richtigen Umgang mit Sicherheitsrisiken und verbessert die Resilienz der eigenen Anwendung gegen moderne Angriffstechniken. Insgesamt reflektieren die aktuellen Best Practices die evolutionären Anforderungen der heutigen digitalen Ökosysteme. Entwickler sind gut beraten, diese Empfehlungen zügig umzusetzen, um sowohl in Bezug auf Nutzervertrauen als auch gesetzliche Anforderungen wie Datenschutzrichtlinien auf der sicheren Seite zu sein.
OAuth 2.1, das diese Erkenntnisse integrativ aufnimmt, steht bereits in den Startlöchern und wird die nächste Generation sicherer Zugriffsprotokolle prägen. Die Implementierung dieser Praktiken verlangt ein gutes Verständnis der zugrundeliegenden Protokolle, der eigenen Architektur und der spezifischen Bedrohungslage. Wer sich dieser Herausforderungen annimmt, legt zugleich den Grundstein für eine robuste und zukunftssichere Zugriffssteuerung, die den Anforderungen moderner Anwendungen und Nutzer gerecht wird.
