OAuth 2.0 – Authorization Code Flow

OAuth ist kein Verschlüsselungsverfahren, sondern ein Protokoll für delegierte Autorisierung. Es löst die Frage: „Wie kann eine App in meinem Namen auf meine Daten bei einem anderen Dienst zugreifen – ohne dass ich der App mein Passwort gebe?“

Die vier Rollen:
  • Resource Owner – du, der Nutzer
  • Client – die App, die Zugriff will
  • Authorization Server – stellt Tokens aus (z. B. Google)
  • Resource Server – hält die Daten (z. B. Google API)
1
Nutzer klickt 'Login mit Google'
👤 Nutzer → 🌐 App (Client)
Der Nutzer möchte sich bei einer App anmelden, ohne dort sein Google-Passwort einzugeben.
2
App leitet zum Authorization Server weiter
🌐 App → 🔐 Authorization Server (Google)
Die App schickt den Browser zu Google – mit client_id, redirect_uri, scope und state.
3
Nutzer loggt sich bei Google ein & stimmt zu
👤 Nutzer → 🔐 Google
Google authentifiziert den Nutzer (Passwort, 2FA) und zeigt den Consent-Screen: 'App XY möchte Zugriff auf Profil und E-Mail – erlauben?'
4
Google schickt Authorization Code zurück
🔐 Google → 🌐 App
Über den Browser-Redirect erhält die App einen kurzlebigen Code. Der Code allein reicht noch nicht – er muss erst gegen ein Token getauscht werden.
5
App tauscht Code gegen Access Token
🌐 App-Backend → 🔐 Google
Direkt von Server zu Server (nicht über den Browser!) – mit client_secret. Das ist der entscheidende Schritt: niemand außer der App kann diesen Tausch machen.
6
Google antwortet mit Access Token (+ Refresh Token)
🔐 Google → 🌐 App
Access Token ist meist ein JWT, gültig z. B. 1 Stunde. Refresh Token kann später ein neues Access Token holen, ohne dass der Nutzer wieder klicken muss.
7
App ruft mit Token die Daten ab
🌐 App → 📦 Resource Server (Google API)
Das Access Token wird im Authorization-Header mitgeschickt. Der Resource Server prüft das Token und liefert die Daten.

Warum nicht einfach Passwort weitergeben?

  1. Die App müsste das Klartext-Passwort speichern – riesiges Risiko.
  2. Der Nutzer könnte den Zugriff nicht gezielt für eine App widerrufen, ohne überall das Passwort zu ändern.
  3. Keine Beschränkung auf Teilrechte (Scopes): „nur lesen“, „nur Profil“ etc.
  4. Kein 2FA möglich, da die App selbst einloggen müsste.

Wichtige Begriffe

Access Token
Kurzlebig, wird bei jedem API-Aufruf mitgeschickt. Oft JWT.
Refresh Token
Langlebig, holt neue Access Tokens ohne erneutes Login.
Scope
Definiert, was die App darf (z. B. „read:email“).
state
Zufallswert gegen CSRF-Angriffe – muss zurückkommen wie geschickt.
PKCE
Erweiterung für native/SPA-Clients ohne client_secret.
OAuth ≠ OpenID Connect. OAuth regelt nur die Autorisierung („darf die App das?“). Wenn du wissen willst wer der Nutzer ist, nutzt man OpenID Connect – eine OAuth-Erweiterung mit einem zusätzlichen id_token (signiertes JWT mit Nutzerinfos).
← TLS & PKIPost-Quantum →