OAuth Teil 1 – Einführung und seine Risiken

Sep. 14, 2025

—

von

Warum OAuth heute unverzichtbar ist

Wer sich heute im Internet bewegt, kommt an OAuth kaum vorbei. Ob beim Login auf einer Social-Media-Plattform, beim Zugriff einer Drittanbieter-App auf deine Cloud-Dateien oder beim Autorisieren eines Smart-TVs für Netflix – überall steckt OAuth 2.0 dahinter.

Das Prinzip ist einfach: Anstatt dein Passwort überall preiszugeben, erteilst du einer Anwendung nur eine spezielle Berechtigung. Diese Berechtigung wird durch ein Token repräsentiert, das genau festlegt, was die Anwendung darf und was nicht.

Ein Beispiel:

Du nutzt eine To-Do-App, die auf deinen Google Kalender zugreifen möchte.
Die App leitet dich zu Google weiter.
Dort meldest du dich an und gibst die Zustimmung.
Google gibt der App ein Access Token, das nur deine Kalenderdaten lesen darf.

So muss die To-Do-App nie dein Google-Passwort kennen. Klingt sicher – und ist es auch, wenn alles korrekt implementiert wird.

Eine Analogie: Hotelschlüssel und Zugangsrechte

Stell dir ein Hotel vor:

Du bist der Gast.
Dein Zimmer entspricht deinen persönlichen Daten.
Das Hotel ist der Autorisierungs-Server.
Eine externe Firma (z. B. der Reinigungsservice) ist die Dritt-App.
Der Zimmerschlüssel ist das Access Token.

Das Hotel übergibt der Reinigungsfirma einen Schlüssel, der nur dein Zimmer öffnet, nicht die Lobby oder andere Gästezimmer.

Doch was, wenn:

der Schlüssel auch den Safe öffnet?
der Schlüssel kopiert wird?
das Hotel versehentlich einen Generalschlüssel ausstellt?

Genau das passiert bei fehlerhaften OAuth-Implementierungen: Zugriff wird zu weit gewährt, Tokens werden ungeschützt gespeichert oder an die falsche Stelle geschickt.

Was OAuth ist – und was nicht

Ein häufiges Missverständnis lautet: „OAuth ist ein Login-System.“
Das ist nicht korrekt.

OAuth = Autorisierung
Es geht darum, ob eine Anwendung bestimmte Aktionen im Namen des Nutzers ausführen darf.
Authentifizierung = Identitätsprüfung
Das ist die Frage: „Wer bist du?“

Für Authentifizierung wird OAuth oft durch OpenID Connect (OIDC) erweitert. OIDC liefert sogenannte ID Tokens, die Informationen über den Benutzer enthalten. Viele Dienste verschmelzen in der Praxis OAuth und OIDC – das macht es für Entwickler und Sicherheitsprüfer noch komplexer.

Typische Einsatzszenarien von OAuth

1. Login mit Drittanbietern

Du klickst auf „Mit Google anmelden“.

Vorteil: Du musst kein neues Passwort erstellen.
Risiko: Fehler in der OAuth-Integration können Angreifern erlauben, deinen Login zu kapern.

2. Zugriff auf Daten durch Apps

Eine Fitness-App möchte deine Spotify-Playlisten lesen.

Vorteil: Sehr feingranulare Steuerung durch „Scopes“.
Risiko: Wenn Scopes zu weit gefasst sind, kann die App viel mehr, als sie eigentlich sollte.

3. Kommunikation zwischen Maschinen

Server A möchte über eine API auf Server B zugreifen.

Vorteil: Mit Client Credentials können sichere, automatisierte Zugriffe eingerichtet werden.
Risiko: Leaks von Tokens in Logs oder Umgebungsvariablen führen hier schnell zu Missbrauch.

Warum OAuth fehleranfällig ist

OAuth selbst ist kein schlechtes System – die Probleme liegen in der Umsetzung.

1. Komplexität

Es gibt verschiedene Flows (Grant Types): Authorization Code, Implicit, Client Credentials, Device Code … Jeder hat eigene Vor- und Nachteile. Wenn Entwickler den falschen Flow nutzen, entstehen Lücken.

2. Viele Akteure

Im Spiel sind mindestens vier Parteien:

Nutzer (Resource Owner)
Anwendung (Client)
Autorisierungs-Server
Ressourcen-Server

Fehler bei der Kommunikation zwischen diesen Rollen führen oft zu Schwachstellen.

3. Alte Implementierungen

Früher war der Implicit Flow Standard für Single-Page-Apps. Heute gilt er als unsicher, weil Tokens in der URL landen. Trotzdem nutzen ihn noch viele Anwendungen.

4. Fehlkonfigurationen

Schon kleine Unachtsamkeiten öffnen Angriffsflächen:

Redirect-URIs, die nicht streng geprüft werden.
Fehlender „state“-Parameter gegen CSRF.
Tokens, die unverschlüsselt im Local Storage liegen.

Beispiele für Risiken

1. Offene Redirects

Wenn eine Anwendung beliebige Umleitungsadressen akzeptiert, kann ein Angreifer den Autorisierungscode oder das Access Token an seine eigene Domain schicken lassen.

Beispiel:

https://auth.example.com/authorize?client_id=123&redirect_uri=https://evil.com

2. Tokens in URLs

Wird ein Access Token in der URL übergeben (#access_token=...), besteht das Risiko, dass es im Referrer-Header oder in Server-Logs landet.

3. Fehlender „state“-Parameter

Der Parameter state dient dazu, CSRF-Angriffe abzuwehren. Fehlt er, kann ein Angreifer den gesamten Flow kapern.

4. Zu breite Scopes

Wenn eine App statt „Lesen“ auch „Schreiben“ darf, kann sie Daten verändern oder löschen.

Warum OAuth-Schwachstellen so kritisch sind

OAuth-Schwachstellen betreffen nicht nur eine einzige Anwendung, sondern oft globale Identitäten.

Ein gekapertes Google-Token kann Zugriff auf Gmail, Google Drive, Kalender und Kontakte bedeuten.
Ein gestohlenes Microsoft-Token öffnet Türen zu Office 365, Teams und Azure.
In Bug-Bounty-Programmen bringen OAuth-Bugs deshalb oft hohe Prämien.

Oauth