Im Folgenden bekommst du eine Einführung in OAuth 2, so dass du danach:

- weißt, was OAuth 2 grundsätzlich ist,
- es von verwandten Konzepten wie „Login mit Google“, OpenID Connect oder reiner Authentifizierung unterscheiden kannst,
- verstehst, welche Probleme OAuth 2 löst – und welche neuen Herausforderungen es mit sich bringt,
- und ein paar praxisnahe Szenarien im Kopf hast.

---

## 1. Grundsätzliche Definition: Was ist OAuth 2?

**Kurze Definition**:  
OAuth 2 ist ein *Autorisierungs*-Framework. Es regelt, wie eine Anwendung (Client) **im Namen eines Benutzers** sicher auf Ressourcen (z. B. APIs, Daten) zugreifen kann, **ohne dass die Anwendung das Passwort des Benutzers kennen muss**.

Es geht also primär um:

- **Zugriffsrechte (Authorization)**
- **Delegation**: „Ich (Nutzer) erlaube App X, auf meine Daten bei Dienst Y zuzugreifen.“

### Zentrales Prinzip

Statt:
- Benutzer gibt sein Passwort direkt bei jeder Drittanbieter-App ein

nutzt man:
- Benutzer loggt sich beim **vertrauenswürdigen Dienst** ein (z. B. Google, GitHub, dein Unternehmens-Identity-Server)
- Dieser Dienst stellt ein **Token** aus (eine Art Eintrittskarte)
- Drittanbieter-App nutzt dieses Token, um beim API-Server Zugriff zu bekommen

Dadurch muss die Drittanbieter-App nie das Passwort sehen – sie bekommt **nur einen begrenzten, kontrollierten Zugriff**.

---

## 2. Die wichtigsten Rollen in OAuth 2

Um Beispiele zu verstehen, braucht man die Standardrollen:

1. **Resource Owner**  
   Der Besitzer der Daten/Ressourcen – meist der **Benutzer**.

2. **Client**  
   Die Anwendung, die im Namen des Benutzers zugreifen möchte  
   (z. B. eine mobile App, eine Web-App, ein Backend-Service).

3. **Resource Server**  
   Die API/das System, das die geschützten Ressourcen bereitstellt  
   (z. B. Google Calendar API, GitHub API, Unternehmens-REST-API).

4. **Authorization Server**  
   Der Server, der:
   - den Benutzer authentifiziert (z. B. Login-Formular) und
   - **Tokens** ausstellt (Access Tokens, optional Refresh Tokens).

Oft sind Authorization Server und Resource Server derselbe technische Dienst, aber **konzeptionell** werden sie getrennt betrachtet.

---

## 3. Grund-Mechanik: Wie läuft ein OAuth-2-Flow ab?

Stark vereinfacht am typischen Web-Szenario:

1. Benutzer nutzt eine Drittanbieter-App (Client) und klickt z. B. auf:
   „Verbinde dich mit meinem Google-Kalender“.

2. Client leitet den Browser zum **Authorization Server** (z. B. accounts.google.com) weiter:
   - mit Angaben wie: „Diese App möchte Zugriff auf Kalenderdaten“.

3. Benutzer loggt sich **beim Authorization Server** ein (falls nicht schon eingeloggt).

4. Benutzer bekommt eine Seite angezeigt:  
   „Die Anwendung X möchte auf Ihre Kalenderdaten zugreifen. Erlauben? (Ja/Nein)“

5. Wenn Benutzer zustimmt:
   - Authorization Server schickt den Benutzer zurück zur App
   - Die App bekommt einen **Authorization Code** (bei einem gängigen Flow).

6. Die App tauscht diesen Code im Hintergrund beim Authorization Server gegen ein **Access Token** (und evtl. ein **Refresh Token**) ein.

7. Die App nutzt das Access Token, um beim **Resource Server** (z. B. Google Calendar API) Daten abzufragen.

Der Benutzer muss sein **Passwort nur beim Authorization Server** eingeben – nicht bei der Drittanbieter-App.

---

## 4. Abgrenzung zu ähnlichen / verwandten Begriffen

### 4.1 OAuth 2 (Authorization) vs. Authentifizierung (Login)

**Authentifizierung**: „Wer bist du?“  
**Autorisierung**: „Worauf darfst du zugreifen?“

- OAuth 2 löst formal **Autorisierung** (Delegation von Zugriffsrechten).
- Viele Systeme nutzen OAuth 2 aber **im Zusammenhang mit Login**, was verwirrend sein kann.

Ein Login mit Google, bei dem eine Anwendung am Ende weiß „dieser User ist Max Mustermann“, basiert meist auf **OpenID Connect**, das **auf OAuth 2 aufsetzt**.

### 4.2 OAuth 2 vs. OpenID Connect (OIDC)

- **OAuth 2**: Spezifiziert, wie Clients **Access Tokens** bekommen, um auf APIs zuzugreifen.
- **OpenID Connect**: Erweiterung auf Basis von OAuth 2, um **Identität** zu transportieren.

OIDC liefert zusätzlich:
- ein **ID Token** (meist ein [[JWT token]]), das Informationen wie:
  - User-ID
  - E-Mail
  - Name
  enthält.

Praxis-Beispiele:

- „Mit Google anmelden“ (Login) → **OpenID Connect**
- „Google Kalender-API nutzen“ → **OAuth 2** (Autorisierung für API-Zugriff)

### 4.3 OAuth 2 vs. API-Key

**API-Key**:
- Meist ein statischer Schlüssel, der im Client eingebaut ist.
- Unterscheidet nicht zwischen verschiedenen Benutzern.
- Hat wenig feingranulare Rechte (oft: „alles oder nichts“).
- Sicherheitsrisiko bei Leaks (z. B. im Frontend-Code).

**OAuth 2**:
- Nutzerbezogen (Access Token repräsentiert den Benutzer/das Delegationsrecht).
- Token haben meist begrenzte Lebensdauer.
- Zugriffsrechte (Scopes) sind feiner steuerbar.

### 4.4 OAuth 2 vs. SAML

- **SAML**: Älterer Standard, XML-basiert, häufig in Unternehmensumgebungen für SSO verwendet.
- **OAuth 2 / OIDC**: JSON/HTTP-basiert, leichtergewichtig, stark im Web- und Mobile-Bereich verbreitet.

Grober Merksatz:
- SAML: klassische Unternehmen, Single Sign-On im Browser, ältere Infrastruktur.
- OAuth 2 + OIDC: moderne Web-/Mobile-Apps, REST-APIs, Microservices.

---

## 5. Welche Probleme löst OAuth 2?

### 5.1 Vermeidung von Passwortweitergabe an Drittanbieter

Früher:  
Eine App wollte auf Gmail zugreifen => Benutzer musste **sein Gmail-Passwort** in dieser App eingeben.  
Risiken:
- App könnte Passwort speichern oder missbrauchen.
- Bei Passwortänderung müsste der Benutzer alles neu einrichten.
- Anbieter (Google) hat keine Kontrolle, welche App das tut.

Mit OAuth 2:
- Benutzer loggt sich nur bei Google ein.
- Drittanbieter-App erhält nur ein **Token mit begrenzten Rechten**, kein Passwort.

**Praxisbeispiel**:  
Eine To-Do-App möchte deine Google Kalender-Einträge anzeigen:  
Du klickst „Mit Google verbinden“, wirst zu Google geleitet, bestätigst die Berechtigungen und die App sieht danach deine Kalender – ohne dein Passwort zu kennen.

### 5.2 Feingranulare Zugriffsrechte (Scopes)

Mit **Scopes** kann eingeschränkt werden, worauf eine App zugreifen darf.

Beispiele:
- `read_calendar`: nur Leserechte auf Kalender
- `write_calendar`: Schreibrechte auf Kalender
- `email`: Zugriff auf deine E-Mail-Adresse
- `profile`: Zugriff auf deine Basisprofildaten

So kann der Benutzer (und auch der Resource Server) klar kontrollieren:
- Eine App darf z. B. **nur lesen**, nicht schreiben.
- Eine App darf **nur auf E-Mail und Profil**, nicht auf Kontakte oder Drive zugreifen.

### 5.3 Zeitlich begrenzte Tokens

**Access Tokens** sind typischerweise kurzlebig (z. B. 5–60 Minuten).

- Wenn ein Token geleakt wird, ist der Schaden zeitlich begrenzt.
- Über Revocation-Mechanismen kann der Zugriff vorzeitig beendet werden.

Optional gibt es **Refresh Tokens**:
- Länger gültig
- Dienen dazu, neue Access Tokens zu holen
- Können vom Authorization Server gezielt deaktiviert werden (z. B. bei Kompromittierung).

### 5.4 Single Sign-On / bessere User Experience (in Kombination mit OIDC)

In Kombination mit OIDC und Single-Sign-On-Konzepten:
- Benutzer loggt sich einmal beim zentralen Identity Provider ein.
- Mehrere Anwendungen können dann in einer Session auf Tokens zugreifen, ohne den Benutzer jedes Mal neu einzuloggen.

---

## 6. Typische OAuth-2-Flows (vereinfacht)

Es gibt verschiedene **„Flows“**, je nach Art des Clients und Nutzungsszenario. Die wichtigsten:

### 6.1 Authorization Code Flow (heute mit PKCE)

Typisch für:
- Web-Anwendungen mit Backend
- Single Page Applications (mit PKCE)
- Mobile Apps

Ablauf (vereinfacht, ohne technische Details):

1. Anwendung leitet Benutzer zum Authorization Server.
2. Benutzer loggt sich ein und stimmt zu.
3. Authorization Server schickt **Authorization Code** an die Anwendung (über Redirect).
4. Anwendung tauscht Code gegen ein **Access Token** (und optional Refresh Token).

**PKCE** (Proof Key for Code Exchange) ist eine Sicherheits-Erweiterung, um Code-Diebstahl zu verhindern, insbesondere bei mobilen/Browser-basierten Apps.

### 6.2 Client Credentials Flow

Für:
- Machine-to-Machine-Kommunikation (kein Benutzer)
- Hintergrundprozesse, Microservices, Server-zu-Server

Hier gibt es keinen Benutzer.  
Der Client identifiziert sich selbst (z. B. mit Client ID + Client Secret) beim Authorization Server und bekommt ein Access Token, um auf eine API zuzugreifen.

**Beispiel**:  
Ein Backend-Service ruft periodisch eine interne Unternehmens-API auf, um Daten zu synchronisieren.

### 6.3 Device Code Flow

Für Geräte ohne vollwertigen Browser oder ohne komfortable Eingabemöglichkeit, wie:
- Smart-TVs
- Konsolen
- IoT-Geräte

Ablauf:
- Gerät zeigt einen Code und eine URL an (z. B. „Bitte gehen Sie auf https://example.com/device und geben Sie Code ABCD ein“).
- Benutzer geht an seinem Smartphone/PC auf diese URL, loggt sich dort ein und bestätigt.
- Gerät bekommt anschließend ein Token und kann auf die Ressource zugreifen.

---

## 7. Herausforderungen und typische Stolperfallen

### 7.1 OAuth 2 ist komplex und flexibel

OAuth 2 ist sehr flexibel – das ist Stärke und Schwäche zugleich:

- Viele Optionen & Erweiterungen → schnell unübersichtlich.
- Viele Entscheidungen zu treffen: Flows, Token-Formate, Scopes, Lifetimes, PKCE, etc.

Für Einsteiger wirkt es oft „überdimensioniert“, vor allem wenn man nur „einen einfachen Login“ braucht (wo eigentlich OIDC gefragt ist).

### 7.2 Verwechslung von OAuth 2 und Login

Weil viele große Anbieter beides kombiniert haben („Login mit Google“), entsteht oft:

- „OAuth 2 ist ein Login-Protokoll.“ → **Formal falsch**, es ist ein Autorisierungsframework.
- Für „Login“ verwendet man **OpenID Connect**, auch wenn technisch OAuth-2-Mechanismen verwendet werden.

Konsequenz:  
Fehlkonzeptionen in Projekten, z. B. versucht man reine OAuth-2-Tokens zu nutzen, um Identität abzuleiten, statt OIDC zu verwenden.

### 7.3 Sicherheitsrisiken bei falscher Implementierung

Einige typische Fehler:

- **Tokens in URLs weitergeben** → landen in Logs, Browser-History, Referrer-Headern.
- **Implicit Flow** für Single-Page-Apps ohne ausreichende Sicherheitsmaßnahmen  
  → gilt inzwischen als überholt; empfohlen wird Authorization Code Flow mit PKCE.
- **Keine Einschränkung der Redirect-URIs** → Angreifer können Redirect-URIs manipulieren und Tokens abfangen.
- **Zu lange gültige Tokens** → höheres Risiko bei Leaks.
- **Speichern von Tokens im unsicheren Speicher** (z. B. localStorage in Browsern) → anfällig für XSS.

### 7.4 Komplexität für Endnutzer

Auch für Endnutzer ist die Zustimmung manchmal nicht klar:

- „Diese App möchte auf Ihr Profil, Ihre Kontakte, Ihre Dateien, Ihre E-Mails zugreifen.“  
  → Viele klicken aus Gewohnheit auf „Zulassen“, ohne zu verstehen, was das bedeutet.

Das ist eher ein UX-/Privacy-Thema, aber eng mit OAuth 2 verbunden, da die Darstellung der **Scopes** oft technisch und verwirrend ist.

---

## 8. Praxisnahe Beispiele

### Beispiel 1: „Mit Google anmelden“ in einer Web-App

**Situation**:  
Du entwickelst eine Web-App, in der sich Nutzer anmelden können. Statt ein eigenes Benutzerkontensystem aufzubauen, willst du „Login mit Google“ anbieten.

**In Wahrheit passiert (typisch)**:
- Die App nutzt **OpenID Connect**:
  - OAuth 2 regelt den Token-Flow.
  - OIDC liefert ein ID Token mit Infos über den Benutzer.
- Nutzer sieht: Google-Login, eine Consent-Seite, und wird danach in deine App zurückgeleitet.
- Deine App bekommt:
  - ein **ID Token** (zur Identifikation des Nutzers)
  - ein **Access Token** (um z. B. zusätzlich auf Google APIs zuzugreifen, falls gewünscht).

**OAuth-2-Aspekt**:  
Der eigentliche Mechanismus, wie Access Token ausgestellt werden, ist OAuth 2.

### Beispiel 2: Drittanbieter-Tool liest GitHub-Repositories

**Situation**:  
Ein Build-Tool oder eine CI/CD-Plattform möchte deine privaten GitHub-Repositories lesen, um Builds auszulösen.

Ablauf:
1. In der CI/CD-Plattform klickst du „Mit GitHub verbinden“.
2. Du wirst zu GitHub weitergeleitet, loggst dich ein.
3. GitHub zeigt dir eine Seite:  
   „Tool X möchte Zugriff auf:
   - Ihre öffentlichen und privaten Repositories
   - Ihre Webhooks
   …“
4. Du erlaubst.
5. Die CI/CD-Plattform erhält ein Access Token mit bestimmten **Scopes** (z. B. `repo`).

**OAuth-2-Aspekt**:
- Das Access Token erlaubt der CI/CD-Plattform, im Namen deines GitHub-Accounts zu agieren, innerhalb des erlaubten Scopes.

### Beispiel 3: Unternehmensinternes Microservice-System

**Situation**:  
In einer Microservice-Architektur gibt es:
- einen zentralen Authorization Server (z. B. Keycloak, Auth0, Azure AD),
- viele Services, die interne APIs bereitstellen.

Szenario:
- Ein Frontend bekommt vom Authorization Server (über einen Login) ein Access Token.
- Dieses Access Token wird vom Frontend bei Aufrufen an das API-Gateway oder direkt an Microservices mitgeschickt.
- Microservices verifizieren das Token und entscheiden anhand von Scopes/Rollen, ob der Zugriff erlaubt ist.

**OAuth-2-Aspekt**:
- Zugriffskontrolle wird zentralisiert.
- Jeder Service muss nicht mehr selbst Benutzer verwalten, sondern nur Access Tokens prüfen.

---

## 9. Zusammenfassung in Stichpunkten

- **OAuth 2** ist ein **Autorisierungs-Framework** (nicht direkt ein Login-Protokoll).
- Es ermöglicht, dass **Drittanbieter-Apps im Namen eines Nutzers** auf Ressourcen zugreifen können, ohne das Passwort des Nutzers zu kennen.
- Wichtige Rollen: **Resource Owner**, **Client**, **Resource Server**, **Authorization Server**.
- Es arbeitet mit **Tokens** (Access Tokens, optional Refresh Tokens) und **Scopes** (feingranulare Rechte).
- Verwandte Standards:
  - **OpenID Connect**: für Authentifizierung/Identität (baut auf OAuth 2 auf).
  - **SAML**: alternative, ältere Lösung v. a. für SSO in Unternehmen.
- Es löst Probleme wie:
  - Passwortweitergabe an Drittanbieter
  - Fehlende Feingranularität von Zugriffsrechten
  - Mangelnde Kontrolle über Zugriffsdelegation
- Herausforderungen:
  - Komplexität und viele Optionen
  - Verwechslungsgefahr mit Authentifizierung
  - Sicherheitsrisiken bei falscher Implementierung
  - UX/Verständlichkeit von Zustimmungsdialogen
- Praxis:
  - „Mit Google/GitHub/Facebook anmelden“
  - Drittanbieter-Apps, die auf APIs zugreifen
  - Microservice-Systeme mit zentralem Identity & Access Management

---