In der Welt moderner Webanwendungen bietet der OAuth-Prozess zuverlässigen Schutz: Er ermöglicht problemlose Logins und Sicherheit beim Teilen von Daten. Doch seine Flexibilität (die auf unterschiedlichste Anwendungsfälle ausgelegt ist) ist zugleich sein wunder Punkt. So kann ein kleiner Fehler bei der URI-Validierung oder ein fehlender State-Check den robusten Token-Austausch in ein mögliches Einfallstor für Cyberkriminelle verwandeln. In diesem Beitrag gehen wir die häufigsten OAuth Schwachstellen durch, erklären, wie diese funktionieren, und zeigen Ihnen konkret, wie sie sich besser rüsten können, bevor ein Angreifer sein Glück versucht.

Was ist OAuth?

OAuth (Open Authorization) ist ein branchenweites Standardverfahren, das eine sichere, tokenbasierte Delegation des Zugriffs auf geschützte Ressourcen ermöglicht, ohne dass Benutzer dabei ihre Anmeldedaten direkt mit Drittanbieter-Anwendungen teilen müssen. Anstatt von Nutzern zu verlangen, dass diese ihre Passwörter freigeben, stellt OAuth Zugriffstokens aus (kurzlebige, zweckgebundene Anmeldeinformationen), die Client-Anwendungen im Namen des Nutzers gegen autorisierte Zugriffsrechte auf APIs oder Dienste eintauschen.

Diese Trennung der Verantwortlichkeiten zwischen Ressourceneigentümer, Ressourcenserver, Client-Anwendung und Autorisierungsserver verringert die Angriffsfläche, da die Zugangsdaten somit weniger oft preisgegeben werden müssen und im Detail kontrolliert werden kann, welcher Operationen welcher Client ausführen kann. In der Praxis bildet OAuth die Grundlage für moderne föderierte Identitätslösungen, die Integration mobiler und Web-Anwendungen sowie Microservices-Architekturen. Es stellt sicher, dass Anwendungen standardisiert und nachvollziehbar miteinander arbeiten können.

Warum bietet OAuth Angriffsfläche?

Die Angreifbarkeit von OAuth liegt weniger in einem Designfehler des Protokolls, sondern vielmehr in seiner inhärenten Komplexität und Flexibilität – denn Implementierende müssen dabei alle Details in Betracht ziehen. OAuth involviert mehrere Parteien (Ressourceneigentümer, Clients, Autorisierungs- und Ressourcenserver), von denen jede ihre eigenen Endpunkte und Parameter (redirect_uri, scope, state, code_challenge usw.) hat. Und durch diese Komplexität muss jeder „Griff“ sitzen und richtig konfiguriert sein. Schon kleine Fehlkonfigurationen (z. B. ungenaue URI-Prüfungen oder fehlendes PKCE) können Angreifern die Türe öffnen. So ermöglicht die kleinste Nachlässigkeit Cyberkiminellen unmittelbar, Codes oder Tokens zu übernehmen.

Kurz: Die Stärke von OAuth (delegierter, tokenbasierter Zugriff) stützt sich auf viele Sicherheitsmechanismen. Wenn Entwickler oder Systemarchitekten Schritte auslassen (wie zum Beispiel State-Prüfungen oder Signaturvalidierung bei ID-Tokens), können Angreifer diese Lücken ausnutzen. Das OAuth selbst ist also nicht „schwach“, aber seine Flexibilität und die vielen optionalen Parameter und Prozesse machen es anfällig für Fehlkonfigurationen, die dann in der realen Welt zu OAuth Schwachstellen werden.

Sieben häufige OAuth Schwachstellen

1. Offene Weiterleitung und Manipulation der Weiterleitungs-URI

So funktioniert es:

• Während des Autorisierungsablaufs registrieren OAuth-Clients eine oder mehrere Weiterleitungs-URIs (Callback-Endpunkte) beim Autorisierungsserver. Wenn diese URIs zu allgemein sind (z. B. https://example.com/*) oder vom Autorisierungsserver nicht streng geprüft werden, kann ein Angreifer eine URL erstellen, die auf eine bösartige Domain oder einen schädlichen Pfad leitet.
• Ein Angreifer bringt den Nutzer dazu, auf einen Link wie folgenden zu klicken:
  • https://auth-server.com/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=https://example.com/evil&state=XYZ
• Da der Autorisierungsserver nicht richtig überprüft, ob https://example.com/evil genau mit dem registrierten https://example.com/callback übereinstimmt, stellt es einen Autorisierungscode oder -token zu der Adresse aus, die vom Angreifer kontrolliert wird.
• Der Angreifer löst diesen Code dann gegen ein Zugriffstoken ein, und verschafft sich somit unautorisierten Zugriff auf die Daten des Opfers.

Schutzmaßnahmen:

• Genaue Übereinstimmung der Weiterleitungs-URIs: Konfigurieren Sie den Autorisierungsserver so, dass nur genau (oder vorregistrierte) Weiterleitungs-URIs erlaubt sind. Wildcards sollten vermieden werden, und nur wenn unbedingt notwendig sehr eingeschränkt eingesetzt werden (z. B. nur auf Subdomain-Ebene nach einer gründlichen Risikobewertung).
• Validierung der Laufzeit: Bei jeder Autorisierungsanfrage muss der Server den redirect_uri-Parameter bytegenau mit der Whitelist vergleichen, die bei der Client-Registrierung hinterlegt wurde.
• Durchsetzung von HTTPS: Lassen Sie nur TLS-geschützte Weiterleitungs-URIs zu, um „Man-in-the-Middle“-Angriffe auf sonst gültige URIs zu verhindern (lehnen Sie zum Beispiel alle HTTP-Varianten ab).

2. Fehlende oder schwache CSRF-/ State-Schutzmechanismen

So funktioniert es:

• OAuths Authorization Code- und Implicit Flows können anfällig für CSRF (Cross-Site Request Forgery) sein, wenn der State-Parameter fehlt oder nicht fest an die Sitzung des Nutzers gebunden ist.
• Ein Angreifer kann vorab eine gültige Autorisierungs-URL mit seiner eigenen client_id und redirect_uri erstellen und dann einen bereits eingeloggten Nutzer dazu bringen, darauf zu klicken. Da im Browser des Opfers eine aktive Sitzung beim OAuth-Anbieter läuft, kann der Anbieter einen Autorisierungscode ausstellen, der an die Redirect-URI des Angreifers gebunden ist.
• Ohne Überprüfung des State-Parameters kann der Client nicht zwischen einer unerwünschten Antwort des Angreifers und einer legitimen Antwort unterscheiden – und das kann möglicherweise dazu führen, dass der Nutzer unwissentlich sein Konto mit dem Dienst des Angreifers verknüpft (Login-CSRF) oder der Angreifer einen Autorisierungscode für den Nutzer erhält.

Schutzmaßnahmen:

• Generieren Sie immer einen eindeutigen State-Wert pro Session: Beim Senden der ersten Autorisierungsanfrage muss der Client einen kryptografisch zufälligen State-Wert erzeugen, diesen in der Sitzung des Nutzers speichern und ihn in die Anfrage einfügen.
• Überprüfen Sie den State-Wert beim Callback streng: Bestätigen Sie beim Empfang des OAuth-Callbacks, ob der zurückgegebene State-Wert genau mit dem zuvor ausgegebenen Wert übereinstimmt. Sollte dieser in irgendeiner Weise abweichen, lehnen Sie die Anfrage sofort ab.
• Nutzen Sie SameSite-Cookies: Die Sitzungs-Cookies sollten mit dem Attribut SameSite=Strict|Lax versehen werden, um das Risiko zu verringern, dass bei externen Anfragen der Authentifizierungskontext mitgesendet wird.

3. Implicit Flow und fehlendes PKCE (Proof Key for Code Exchange, dt: Sicherheitsnachweis für den Code-Austausch)

So funktioniert es:

• Im klassischen Implicit Flow wird das Access Token direkt in der Weiterleitungs-URI zurückgegeben. Dadurch ist es im Browser einsehbar und das Risiko steigt – und genau deshalb ist dieser Ablauf für die meisten Anwendungsfälle inzwischen auch veraltet. Der Client (häufig eine Single-Page-App) erhält das Access Token direkt über einen Fragment-Teil in der Weiterleitungs-URI. Da das Token in dem Browser einsehbar ist, kann ein Angreifer, der ein bösartiges Skript oder ein kompromittiertes Netzwerk kontrolliert, dieses abfangen.
• Der Authorization Code Flow ist ein zweistufiger OAuth-Flow, bei dem der Client einen kurzlebigen Autorisierungscode (den er über eine Server-Weiterleitung erhält) gegen ein Zugangs-Token eintauscht. Dies erhöht die Sicherheit, da Tokens nicht im Browser gespeichert werden. Wenn der Client allerdings kein PKCE (Proof Key for Code Exchange) implementiert, könnte ein Angreifer, der der den Weiterleitungskanal abhört (z. B. eine bösartige mobile App mit derselben client_id), den Autorisierungscode abfangen und für den Zugriff auf das Access Token des berechtigten Nutzers verwenden.

Schutzmaßnahmen:

• Verwenden Sie für alle öffentlichen Clients den Authorization Code Flow mit PKCE: Indem von jedem öffentlichen Client (mobil, SPA, Desktop) für jede Anfrage die Erzeugung eines individuelles Code-Verifiers und die Sendung einer Code-Challenge sendet verlangt wird, bindet der Autorisierungsserver den ausgegebenen Code an diesen Verifier. Selbst wenn jemand den Code abhört, kann er ihn ohne den ursprünglichen Code-Verifier nicht einlösen.
• Stellen Sie den Implicit Flow: In modernen Best Practices wird grundsätzlich vom Implicit Flow abgeraten. Autorisierungsserver und Clients sollten standardmäßig so konfiguriert werden, dass PKCE verwendet wird und nur Autorisierungscodes zurückgegeben werden (und Tokens über einen Back-Channel geliefert werden). So können Sie diese Art von OAuth Schwachstellen im Keim ersticken.

4. Unzureichende Validierung des Zugriffsbereichs und zu weit gefasste Berechtigungen

So funktioniert es:

• Wenn ein Client Berechtigungen anfordert, kann er möglicherweise Zugriffsbereiche (Scopes) verlangen, die weit über das tatsächlich benötigte Maß hinausgehen. Und wenn der Ressourceninhaber versehentlich all diesen Scopes zustimmt, kann der Client (und jeder Angreifer, der ihn später kompromittiert) auf Daten zugreifen oder Aktionen ausführen, die weit über das Notwendige hinausgehen.
• Angreifer können Nutzer durch Social Engineering oder Phishing dazu bringen, hochprivilegierte Zugriffsbereiche freizugeben, und anschließend mit diesen Tokens missbräuchlich Rechte zu erweitern oder auf andere Ressourcen zugreifen.

Schutzmaßnahmen:

• Prinzip der minimalen Rechtevergabe (Principle of Least Privilege, PoLP): Fordern Sie stets nur das Minimum an Scopes an, das für eine bestimmte Funktion erforderlich ist. Überprüfen Sie die UI/UX-Abläufe, um sicherzustellen, dass Endnutzer genau verstehen, welchen Daten sie zustimmen.
• Serverseitige Durchsetzung: Überprüfen Sie auf dem Ressourcenserver, dass die Scopes des Access Tokens mit der angeforderten Aktion übereinstimmen. Lehnen Sie API-Aufrufe ab, bei denen Scopes fehlen oder nicht ausreichen.
• Granularität der Scopes: Entwerfen Sie bei der Registrierung von APIs fein granulare Scopes (z. B. invoices:read vs. invoices:write anstelle eines einzigen Invoices-Scopes). Dadurch verhindern Sie, dass Nutzer vollständige CRUD-Berechtigungen erhalten, wenn nur Leserechte benötigt werden.

5. Token-Leck durch unsichere Speicherung oder Transport

So funktioniert es:

• Auf den Local Storage, Session Storage oder Cookies ohne HttpOnly-Attribut von Browsern kann durch bösartiges JavaScript zugegriffen werden, das aufgrund von Cross-Site-Scripting-Schwachstellen (XSS) ausgeführt wird. Wenn Access Tokens (oder Refresh Tokens) an diesen Speicherorten abgelegt werden, kann ein Angreifer sie stehlen und API-Aufrufe im Namen des Nutzers durchführen.
• Tokens, die über nicht-TLS-geschützte (HTTP-)Verbindungen oder mit schlecht implementierter TLS-Konfigurationen (z. B. das Akzeptieren selbstsignierter Zertifikate) übertragen werden, sind dem Risiko von Netzwerk-Lauschangriffen ausgesetzt.

Schutzmaßnahmen:

• Verwenden Sie sichere, mit HttpOnly gekennzeichnete Cookies zur Speicherung von Tokens: Indem Sie HttpOnly-Flags auf Cookies setzen, verhindern Sie, dass clientseitige Skripte die Tokens lesen oder verändern können.
• Setzen Sie überall TLS um: Alle Endpunkte (Autorisierung, Token, Ressource) müssen HTTPS mit starker Verschlüsselung verwenden. Implementieren Sie HTTP Strict Transport Security (HSTS), um Downgrade-Angriffe zu verhindern.
• Kurzlebige Access Tokens + rotierende Refresh-Tokens: Geben Sie Tokens mit minimaler Lebensdauer aus (z. B. 5–15 Minuten) und tauschen Sie Refresh Tokens bei jeder Verwendung aus. Das verkleinert das Zeitfenster für einen möglichen Angriff maßgeblich – auch dann, wenn ein Token gestohlen wird.

6. Fehlende oder ineffektive Token-Widerrufsfunktion

So funktioniert es:

• Wenn ein Nutzer einer Anwendung den Zugriff entzieht (z. B. über das Benutzerkonto-Dashboard), der Autorisierungsserver jedoch bestehende Access- oder Refresh-Tokens nicht sofort widerruft oder auf eine Blacklist setzt, kann der Client weiterhin so agieren, als wäre er noch autorisiert. Im Falle einer Kompromittierung des Clients kann ein Angreifer die APIs unbegrenzt weiter aufrufen.
• Manche Implementierungen geben den Widerruf nicht an föderierte Dienste oder nachgelagerte Ressourcenserver weiter, und dadurch bleiben veraltete Tokens weiterhin gültig.

Schutzmaßnahmen:

• Implementieren Sie einen Widerrufsendpunkt: Befolgen Sie RFC 7009, indem Sie einen Endpunkt bereitstellen, über den Clients (oder Nutzer) Access- und Refresh-Tokens ausdrücklich ungültig machen können.
• Kurze Token-Lebensdauer + kontinuierliche Validierung: Neben dem Widerruf sollten Sie Ressourcenserver so konfigurieren, dass diese bei jedem API-Aufruf die Token-Metadaten prüfen (z. B. über Introspektions-Endpunkte) oder eine Blacklist für widerrufene Tokens führen.
• Drittdienste benachrichtigen: Stellen Sie in föderierten Setups (z. B. SAML-↔-OAuth-Bridge-Architekturen) sicher, dass Widerrufsereignisse an alle nachgelagerten Anbieter weitergeleitet werden, damit veraltete Tokens nicht anderweitig verwendet werden können.

7. Selbstentwickelte oder veraltete OAuth-Implementierungen

So funktioniert es:

• Manchmal versuchen Entwickler, eigene Lösungen zu programmieren, oder verlassen sich auf veraltete Bibliotheken, die nicht vollständig den aktuellen Best Practices von OAuth 2.1 und OpenID Connect entsprechen. Das kann zu subtilen logischen Fehlern führen – so kann zum Beispiel die Validierung der id-token-Signaturen ausgelassen werden, Audience Claims (aud) können ignoriert oder Client-Secrets bei einem öffentlichen Client wiederverwendet werden.
• Ein eigener Code akzeptiert möglicherweise vom Nutzer übergebene Parameter ohne diese angemessen zu prüfen oder überspringt obligatorische Sicherheitsprüfungen (z. B. das Nicht-Verifizieren des Nonce in OIDC) – und das öffnet die Türe zu Replay-Angriffen, einem Token-Austausch oder einer unbefugten Identitätsübernahme.

Schutzmaßnahmen:

• Verwenden Sie gut gepflegte Bibliotheken und Frameworks: Bevorzugen Sie SDKs, die von Herstellern unterstützt oder von der Community geprüft wurden (z. B. Auth0-Clientbibliotheken, OAuth-Module von Spring Security) und regelmäßig aktualisiert werden. Somit können Änderungen der OAuth 2.1- und IANA-Spezifikationen berücksichtigt werden.
• Führen Sie gründliche Code-Reviews und Bedrohungsanalysen durch: Bei jeder individuellen Integration (z. B. Anbindung eines externen Identity-Providers) sollten Sie eine Bedrohungsmodellierung durchführen, die sich jeden Schritt des Ablaufs ansieht und sicherstellt, dass alle Parameter (iss, aud, nonce, exp, state) korrekt überprüft werden.
• Bleiben Sie bei RFCs und Sicherheitshinweisen auf dem Laufenden: OAuth-bezogene Sicherheitslücken (CVEs) und Best Practices entwickeln sich schnell weiter. Abonnieren Sie die OAuth Security Mailing List und prüfen Sie Ihre Konfiguration regelmäßig anhand der neuesten IETF-Empfehlungen (z. B. obligatorisches PKCE, Abschaffung des Implicit Flow, wenn möglich Anforderung eines Proof of Possession).

Die wichtigsten Erkenntnisse zu OAuth Schwachstellen

• Für eine resiliente OAuth-Implementierung sollten eine strikte Validierung der Weiterleitungs-URIs, der State-Parameter und der Tokensignaturen durchgesetzt werden. Verwenden Sie PKCE für alle öffentlichen Clients und fordern Sie Berechtigungen immer nach dem Least-Privilege-Prinzip an.
• Sorgen Sie für eine sichere Speicherung und Übertragung von Tokens (indem Sie HttpOnly-Cookies gegenüber dem lokalen Speicher bevorzugen), und richten Sie eine Token-Widerrufsfunktion mit kontinuierlicher Introspektion ein.
• Verwenden Sie von der Community empfohlene OAuth-Bibliotheken, halten Sie sich über aktuelle Richtlinien zu IETF/OAuth2.1 auf dem Laufenden und betreiben Sie ein zuverlässiges Logging/Monitoring, um Missbrauch frühzeitig zu erkennen.

Wenn Organisationen proaktiv Maßnahmen gegen diese häufigen OAuth Schwachstellen unternehmen, können Sie das Risiko von Zugangsdatendiebstahl, unbefugtem API-Zugriff und großflächigen Datenschutzverletzungen aufgrund fehlerhafter OAuth-Integrationen verringern.

Finden Sie OAuth Schwachstellen mit PTaaS von Outpost24

In der sich schnell entwickelnden Bedrohungslandschaft sollten Sie sich nicht darauf verlassen, sporadische manuelle Sicherheitsassesments vorzunehmen, da OAuth Schwachstellen dabei wochen- oder sogar monatelang unentdeckt bleiben können.

Durch die Nutzung von Outpost24’s Pen-Testing-as-a-Service-(PTaaS)-Lösung erhalten Sicherheitsteams eine kontinuierliche, (fast vollständig durch menschliche Experten manuelle) Analyse der neuesten OAuth-Angreifvektoren. Dabei werden offene Weiterleitungslinks, fehlerhafte PKCE-Implementierungen, übermäßig vergebene Scopes und Fehler bei der ToSpeicherung von Tokens identifiziert, bevor diese in der realen Welt ausgenutzt werden können.

Beginnen Sie noch heute damit, Ihre OAuth-Implementierungen kontinuierlich zu analysieren und zu schützen, um das Risiko in Ihren Web- und Mobilanwendungen zu verringern und fordern Sie eine Demo der PTaaS-Lösung von Outpost24 an.

Oder erfahren Sie mehr darüber, wie die CyberFlex-Lösung von Outpost24s PTaaS mit External Attack Surface Management (EASM) ihre Web-Application-Angriffsfläche noch transparenter und sicherer macht.