Teil 4 – Wie der OAuth Flow funktioniert

Sep. 14, 2025

—

von

Warum ein genauer Blick wichtig ist

In den ersten Teilen haben wir über die Grundlagen gesprochen und die verschiedenen Grant Types verglichen. Doch so richtig klar wird OAuth erst, wenn man einmal den kompletten Ablauf Schritt für Schritt durchgeht. Wir konzentrieren uns hier auf den Authorization Code Flow mit PKCE, weil er heute der Standard und die sicherste Wahl für Web-Apps, Mobile-Apps und Single-Page-Anwendungen ist.

Der Ablauf in 7 Schritten

1. Der Benutzer startet den Login

Beispiel: Auf einer Website klickst du auf „Mit Google anmelden“.

Die Anwendung (Client) leitet dich jetzt zum Autorisierungs-Server weiter. Dort wird ein spezieller Request aufgebaut:

GET https://accounts.google.com/o/oauth2/v2/auth?
  response_type=code
  &client_id=123456789.apps.googleusercontent.com
  &redirect_uri=https://app.example.com/callback
  &scope=email profile
  &state=xyzABC123
  &code_challenge=HASHwert
  &code_challenge_method=S256

response_type=code → Wir wollen einen Autorisierungscode.
client_id → eindeutige Kennung der App.
redirect_uri → wohin die Antwort geschickt wird.
scope → welche Rechte die App haben will.
state → schützt vor CSRF.
code_challenge → PKCE-Mechanismus, Hash eines Geheimwerts.

2. Der Benutzer authentifiziert sich

Der Autorisierungs-Server (z. B. Google) zeigt eine Login-Seite.

Du gibst Benutzername und Passwort ein.
Der Server prüft deine Identität.
Oft gibt es zusätzliche Sicherheitsstufen wie 2FA.

👉 Wichtiger Punkt: Das Passwort geht nur an den Autorisierungs-Server, niemals an die Dritt-App.

3. Der Benutzer stimmt zu

Nach erfolgreichem Login fragt dich der Server:

„Diese App möchte deine E-Mail-Adresse und dein Profil sehen. Erlaubst du das?“

Du klickst auf „Zulassen“. Damit gibst du dem Client explizit die Rechte, die in scope angefragt wurden.

4. Der Autorisierungs-Server leitet zurück

Jetzt wirst du zur angegebenen Redirect URI geschickt, z. B.:

https://app.example.com/callback?code=AUTHCODE123&state=xyzABC123

code = Autorisierungscode (kurzlebig, z. B. 30 Sekunden gültig).
state = muss mit dem ursprünglichen Wert übereinstimmen.

👉 Typische Schwachstelle:
Wenn die App den state nicht prüft, ist der Flow anfällig für CSRF-Angriffe.

5. Der Client tauscht den Code ein

Die Anwendung (Backend-Server) schickt jetzt einen Request an den Token-Endpunkt des Autorisierungs-Servers:

POST https://oauth2.googleapis.com/token
Content-Type: application/x-www-form-urlencoded

code=AUTHCODE123
&client_id=123456789.apps.googleusercontent.com
&client_secret=SuperSecret (nur bei Confidential Clients)
&redirect_uri=https://app.example.com/callback
&grant_type=authorization_code
&code_verifier=OriginalGeheimwert

code_verifier = der originale Geheimwert für PKCE.
Der Server überprüft, ob SHA256(code_verifier) = code_challenge.

Wenn ja → alles ok, sonst → Ablehnung.

6. Der Client bekommt ein Token

Die Antwort:

{
  "access_token": "ya29.A0ARrdaM...",
  "expires_in": 3600,
  "refresh_token": "1//0gfh34...",
  "scope": "email profile",
  "token_type": "Bearer"
}

access_token → darf für eine Stunde genutzt werden.
refresh_token → kann neue Tokens anfordern.
scope → bestätigt, welche Rechte vergeben wurden.

👉 Typische Schwachstelle:
Wenn Tokens im Local Storage oder in der URL landen, können sie leicht gestohlen werden.

7. Zugriff auf den Ressourcen-Server

Jetzt kann die App im Namen des Nutzers Daten abrufen:

GET https://www.googleapis.com/oauth2/v1/userinfo
Authorization: Bearer ya29.A0ARrdaM...

Der Ressourcen-Server prüft das Token:

Ist es gültig?
Ist es noch nicht abgelaufen?
Hat es die nötigen Scopes?

Dann gibt er die angefragten Daten zurück.

Wo entstehen Sicherheitsprobleme?

1. Redirect URI

Wenn eine Anwendung Wildcards wie redirect_uri=https://*.example.com erlaubt, kann ein Angreifer eine Subdomain kontrollieren und den Code oder das Token abfangen.

2. State

Fehlt der state-Parameter oder wird er nicht überprüft, sind CSRF-Angriffe möglich.

3. Token-Speicherung

Tokens dürfen nicht in der URL auftauchen (z. B. im Implicit Flow).
Sie sollten nur in sicheren HttpOnly-Cookies gespeichert werden.

4. Refresh Tokens

Langlebige Refresh Tokens sind praktisch, aber gefährlich.
Werden sie im Browser gespeichert, reicht ein einziger XSS-Angriff, um sie zu stehlen.

5. PKCE

Ohne PKCE kann ein Angreifer einen Autorisierungscode abfangen und selbst einlösen.

Ein reales Beispiel: Offene Redirects

Angenommen, eine App akzeptiert folgende Redirect URI:

https://app.example.com/*

Ein Angreifer findet heraus, dass https://app.example.com/evil auf seine eigene Seite weiterleitet.
Er baut eine URL wie:

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

→ Ergebnis: Der Autorisierungscode landet direkt beim Angreifer.