Warum es verschiedene Grant Types gibt
OAuth soll in vielen Szenarien funktionieren:
- Mobile Apps ohne sicheren Server.
- Webanwendungen mit eigenem Backend.
- Geräte ohne Browser (z. B. Smart-TVs).
- Kommunikation zwischen Servern.
Darum gibt es verschiedene Grant Types (Autorisierungsarten). Jeder Typ ist für einen bestimmten Anwendungsfall gedacht – aber nicht jeder ist gleich sicher. Viele Schwachstellen in realen Anwendungen entstehen dadurch, dass ein ungeeigneter Flow verwendet wird.
1. Authorization Code Flow (Standard)
Ablauf in Kurzform
- Der Nutzer klickt „Login mit Google“.
- Der Client leitet zum Autorisierungs-Server weiter.
- Der Nutzer loggt sich ein und stimmt zu.
- Der Server gibt einen Authorization Code zurück (über die Redirect URI).
- Der Client tauscht den Code gegen ein Access Token (und ggf. Refresh Token) ein.
Vorteile
- Sehr sicher, weil das Access Token nicht direkt im Browser landet.
- Ideal für klassische Webanwendungen mit Backend.
Risiken
- Wenn der Code abgefangen wird, kann er von einem Angreifer gegen ein Token eingetauscht werden.
- Darum ist hier oft PKCE nötig (Proof Key for Code Exchange).
👉 Heute der empfohlene Standard für fast alle Szenarien.
2. Authorization Code Flow mit PKCE
Was ist PKCE?
PKCE (ausgesprochen „Pixy“) = Proof Key for Code Exchange.
- Der Client erstellt vor der Weiterleitung eine Art Geheimcode (Code Verifier).
- Davon wird ein Hash (Code Challenge) an den Autorisierungs-Server geschickt.
- Später beim Eintauschen des Codes muss der Client den Originalwert vorlegen.
Vorteil
- Selbst wenn ein Angreifer den Code stiehlt, kann er ihn nicht einlösen, weil ihm der Code Verifier fehlt.
Einsatz
- Vor allem bei mobilen Apps oder Single-Page-Anwendungen, wo kein sicherer Server existiert.
👉 Seit OAuth 2.1 ist PKCE Pflicht für alle Public Clients.
3. Implicit Flow (unsicher, veraltet)
Ablauf
- Der Nutzer wird eingeloggt.
- Statt eines Codes gibt es direkt ein Access Token zurück – meist im URL-Fragment (
#access_token=...).
Vorteile
- Früher gedacht für Single-Page-Apps, um den Zwischenschritt mit dem Code zu sparen.
Risiken
- Das Token landet im Browser-Adressfeld.
- Kann über Referrer, Browser-Extensions oder Server-Logs geleakt werden.
- Keine Möglichkeit, Refresh Tokens sicher zu nutzen.
👉 Heute nicht mehr empfohlen. Wurde in OAuth 2.1 offiziell abgeschafft.
4. Client Credentials Flow
Ablauf
- Kein Benutzer im Spiel, nur Maschinen.
- Der Client authentifiziert sich mit Client-ID + Client-Secret beim Autorisierungs-Server.
- Bekommt ein Access Token zurück.
Einsatz
- Kommunikation von Server zu Server.
- Beispiel: Ein Zahlungsdienst spricht mit der API eines Shops.
Risiken
- Secrets müssen sicher gespeichert werden.
- Bei Missbrauch: Vollzugriff auf Ressourcen ohne Benutzereinwilligung.
👉 Sicher, wenn richtig konfiguriert und Secrets geschützt sind.
5. Resource Owner Password Flow (ROP Flow)
Ablauf
- Der Benutzer gibt direkt sein Passwort in der Dritt-App ein.
- Die App tauscht Benutzername und Passwort gegen ein Access Token ein.
Risiken
- Der Client sieht das Passwort im Klartext.
- Ein kompromittierter Client kann Passwörter stehlen.
- Keine Trennung zwischen Nutzer und App.
👉 Veraltet und unsicher. Sollte nicht mehr genutzt werden.
6. Device Code Flow
Ablauf
- Für Geräte ohne Browser (Smart-TV, Spielkonsole).
- Nutzer sieht auf dem Bildschirm einen Code (z. B.
ABCD-1234). - Er geht an einen anderen Computer/Smartphone, ruft eine Website auf, gibt den Code ein und loggt sich dort ein.
- Das Gerät fragt regelmäßig beim Server nach, ob der Code eingelöst wurde.
Vorteile
- Ermöglicht sichere Nutzung auf Geräten ohne Eingabemöglichkeiten.
Risiken
- Rateversuche bei den Codes, wenn keine Sperre eingebaut ist.
- Unsichere Implementierungen können Tokens zu lange gültig lassen.
Vergleich der Flows
| Flow | Geeignet für | Risiken | Empfehlung |
|---|---|---|---|
| Authorization Code | Web-Apps mit Backend | Code-Diebstahl ohne PKCE | Empfohlen |
| Authorization Code + PKCE | Mobile & SPAs | Wenn PKCE fehlt: Code-Replay möglich | Pflicht für Public Clients |
| Implicit | Alte SPAs | Token-Leak über URL | Unsicher, nicht mehr nutzen |
| Client Credentials | Server-zu-Server | Secret-Leaks | Sicher bei guter Speicherung |
| Resource Owner Password | Alte Apps | Passwortweitergabe | Veraltet, vermeiden |
| Device Code | Smart-TVs, Konsolen | Code-Raten, langsame Polling-Schwächen | Empfohlen für Geräte |
Typische Fehler bei der Wahl des Flows
- SPA mit Implicit Flow statt PKCE
→ Tokens landen in der URL, leicht abfangbar. - Server-zu-Server ohne Secrets
→ Unsichere Speicherung, z. B. in Code-Repositories. - ROP Flow für Benutzerlogins
→ Benutzer-Passwörter landen bei Drittanbietern. - Refresh Tokens im Browser
→ Ein Angreifer mit XSS kann Dauerzugriff bekommen.
Schreibe einen Kommentar