Teil 5 – Erkennen von OAuth-Diensten

Sep. 14, 2025

—

von

Warum dieser Schritt wichtig ist

Bevor man Sicherheitsprobleme ausnutzen oder beheben kann, muss man überhaupt wissen, wo OAuth im Einsatz ist. Oft ist OAuth nicht auf den ersten Blick sichtbar:

Manchmal versteckt es sich in Login-Flows.
Manchmal in API-Aufrufen, die Tokens brauchen.
Manchmal in versteckten Konfigurationsdateien.

In diesem Teil schauen wir uns an, wie man OAuth-Dienste in einer App oder Website identifizieren kann.

Erste Hinweise im Frontend

Login-Buttons

Das Offensichtlichste: Buttons wie „Mit Google anmelden“, „Mit GitHub verbinden“ oder „Mit Facebook einloggen“.

Dahinter steckt fast immer ein OAuth-Flow.
Klickt man auf den Button, landet man auf einer URL, die nach authorize aussieht.

👉 Beispiel:

https://accounts.google.com/o/oauth2/v2/auth?client_id=123&redirect_uri=https://app.example.com/callback&scope=email

Redirects im Browser

Mit den Entwicklertools (z. B. Chrome DevTools, Tab „Netzwerk“) kann man den Ablauf genau verfolgen.

Siehst du einen Request an /authorize? → Klarer Hinweis auf OAuth.
Wird ein code oder access_token in der URL zurückgeschickt? → Dann läuft der OAuth-Flow.

Scopes im Klartext

Oft sieht man in den URLs oder Formularen etwas wie:

scope=email profile openid

Das sind die Berechtigungen, die eine Anwendung anfragt.

Je breiter die Scopes, desto interessanter für Angreifer.
openid weist darauf hin, dass zusätzlich OpenID Connect im Spiel ist.

Typische Endpunkte

Ein OAuth-Flow nutzt bestimmte Standard-Endpunkte:

Authorization Endpoint → hier startet alles, oft /authorize.
Token Endpoint → hier werden Codes gegen Tokens eingetauscht, oft /token.
UserInfo Endpoint (bei OIDC) → liefert Daten wie Name, E-Mail.
Revocation/Introspection Endpoints → zum Widerrufen oder Prüfen von Tokens.

👉 Beispiele (Google):

Autorisierung: https://accounts.google.com/o/oauth2/v2/auth
Token: https://oauth2.googleapis.com/token
UserInfo: https://openidconnect.googleapis.com/v1/userinfo

Discovery-Dokumente

Viele Anbieter veröffentlichen sogenannte „Discovery-Dokumente“.

URL: https://<domain>/.well-known/openid-configuration
Enthält JSON mit allen wichtigen Infos: Endpunkte, unterstützte Flows, Signatur-Schlüssel (JWKs).

👉 Beispiel (gekürzt):

{
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs"
}

Nutzen für Sicherheitsprüfer:

Sofortiger Überblick über alle Endpunkte.
Hinweise auf unterstützte Flows.
Kann helfen, Schwächen wie unsichere Redirect-URIs zu finden.

Identifizierung im Code

JavaScript & HTML

In vielen Single-Page-Apps sieht man in den JavaScript-Dateien:

client_id=...
redirect_uri=...
scope=...

👉 Das verrät: welche OAuth-Provider genutzt werden, welche Rechte angefragt werden, und oft auch, ob PKCE implementiert ist.

Mobile Apps

Bei Android/iOS-Apps kann man oft in der App-Konfiguration (z. B. strings.xml) client_id und redirect_uri finden.

Das zeigt, wie der OAuth-Flow gebaut ist.
Manche Apps nutzen Custom URI Schemes (myapp://callback) → oft ein Angriffspunkt.

Server-Konfigurationen

In Repositories oder .env-Dateien findet man häufig:

OAUTH_CLIENT_ID
OAUTH_CLIENT_SECRET
OAUTH_REDIRECT_URI

👉 Für Angreifer Gold wert, wenn diese Daten öffentlich landen (z. B. GitHub-Leak).

Hinweise in Tokens selbst

Ein Access Token kann verschiedene Formen haben.

Manche sind einfache Strings (opaque Tokens).
Andere sind JWTs (JSON Web Tokens).

JWTs kann man leicht dekodieren (z. B. mit jwt.io) und sieht dann:

iss (Issuer → welcher OAuth-Provider).
aud (Audience → für welche Anwendung gedacht).
exp (Ablaufdatum).

👉 Dadurch lässt sich der zugrunde liegende OAuth-Dienst identifizieren.

Tools zum Erkennen von OAuth

Burp Suite → Proxy einschalten, Login-Flow durchlaufen, nach /authorize und /token suchen.
OWASP ZAP → ähnlich, gute Automatisierungsmöglichkeiten.
DevTools (F12) → ideal, um im Netzwerk-Tab Scopes und Redirects zu sehen.
Google dorking → Suche nach .well-known/openid-configuration bei bekannten Domains.
jwt.io → zum schnellen Analysieren von Tokens.

Typische Anzeichen für Fehlkonfigurationen

Offene Redirect-URIs
- Wenn du redirect_uri=https://evil.com in die URL eintragen kannst und der Server es akzeptiert.
Fehlender State
- Wenn kein state-Parameter in den Requests auftaucht.
Zu breite Scopes
- Wenn eine App scope=full_access oder scope=all anfragt.
Unsichere Token-Speicherung
- Tokens tauchen in der URL oder im Local Storage auf.

Warum Erkennen so entscheidend ist

Manche Sicherheitsprüfer springen direkt zu Exploits. Doch ohne zu verstehen, welche Endpunkte da sind, welche Scopes angefragt werden und wie Tokens gespeichert werden, übersieht man leicht die größten Schwachstellen.

Für Entwickler gilt: Schon beim Design sollte klar sein, welche Flows nötig sind, welche Endpunkte es gibt und welche Parameter wirklich gebraucht werden. Alles andere ist unnötige Angriffsfläche.