work/notes/nextcloud/Notes/IT-Know-How/web und cloud gedöns/OAuth2.md at 395419fc35a3e4f3e7ef5cab9120b91774324847

mathias2784/work

Fork 0

Files

T

Mathias Schneider fc3aef4da8 add synced notes on IT know how

2026-03-17 19:01:50 +01:00

14 KiB

Executable File

Raw Blame History

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:

Resource Owner
Der Besitzer der Daten/Ressourcen – meist der Benutzer.
Client
Die Anwendung, die im Namen des Benutzers zugreifen möchte
(z. B. eine mobile App, eine Web-App, ein Backend-Service).
Resource Server
Die API/das System, das die geschützten Ressourcen bereitstellt
(z. B. Google Calendar API, GitHub API, Unternehmens-REST-API).
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:

Benutzer nutzt eine Drittanbieter-App (Client) und klickt z. B. auf: „Verbinde dich mit meinem Google-Kalender“.
Client leitet den Browser zum Authorization Server (z. B. accounts.google.com) weiter:
- mit Angaben wie: „Diese App möchte Zugriff auf Kalenderdaten“.
Benutzer loggt sich beim Authorization Server ein (falls nicht schon eingeloggt).
Benutzer bekommt eine Seite angezeigt:
„Die Anwendung X möchte auf Ihre Kalenderdaten zugreifen. Erlauben? (Ja/Nein)“
Wenn Benutzer zustimmt:
- Authorization Server schickt den Benutzer zurück zur App
- Die App bekommt einen Authorization Code (bei einem gängigen Flow).
Die App tauscht diesen Code im Hintergrund beim Authorization Server gegen ein Access Token (und evtl. ein Refresh Token) ein.
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

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):

Anwendung leitet Benutzer zum Authorization Server.
Benutzer loggt sich ein und stimmt zu.
Authorization Server schickt Authorization Code an die Anwendung (über Redirect).
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).

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.