OAuth2 und OpenID Connect

In L5 hast du JWT kennengelernt: ein signiertes Token, mit dem sich ein Client gegenüber einer API ausweist. Aber wie kommt der Client an dieses Token? In einer einfachen App reicht ein Login mit Username/Passwort. In modernen Systemen ist das viel komplizierter: was ist, wenn drei Apps von einem Hersteller dieselben User-Accounts nutzen sollen? Wenn eine Drittanbieter-App auf deine Google-Kalender-Daten zugreifen will, ohne dein Passwort zu kennen? Wenn dein Backend zu vielen anderen Services reden muss, ohne überall extra Logins?

Hier kommt OAuth 2.0 ins Spiel – der Industriestandard für delegierte Autorisierung. Du kennst es vom Knopf „Mit Google anmelden", „Mit GitHub fortfahren", „Mit Facebook einloggen". Diese Lektion erklärt das System dahinter, die Rollen, die Flows (Grant Types) und den wichtigsten Aufbau-Standard OpenID Connect – kurz OIDC – der OAuth2 um echte Authentifizierung ergänzt.

1) Das Problem, das OAuth2 löst

Stell dir vor: eine Foto-Druck-App möchte deine Fotos von Google Photos drucken. Vor OAuth gab es zwei schreckliche Optionen: entweder du gibst der App dein Google-Passwort (die App hat dann Vollzugriff auf alles!), oder du musst Fotos händisch hoch- und wieder runterladen. Die erste Option ist eine Sicherheitskatastrophe – die App könnte deine E-Mails lesen, dein Konto übernehmen, alles.

OAuth2 löst das mit einer eleganten Idee: delegierte Autorisierung. Die Foto-App bekommt einen speziellen Token, der nur Lese-Zugriff auf Fotos erlaubt – nichts anderes. Dein Passwort sieht die App nie. Du kannst die Berechtigung jederzeit widerrufen. Eine schöne Analogie: ein Hotel-Keycard. Du bekommst sie an der Rezeption, sie öffnet nur dein Zimmer und vielleicht den Pool, nicht alle anderen Räume. Du kannst sie zurückgeben oder verlieren – das Hotel deaktiviert sie und das Schloss-System ist sofort wieder sicher.

2) Die vier Rollen

OAuth2 definiert vier Rollen, die jede in einem typischen Flow vorkommen. Diese Begriffe in IHK-Klausuren kennen ist Pflicht:

Die vier Rollen in OAuth2

Resource Owner

Der User. Besitzer der Daten, gibt seine Erlaubnis. Du, der seine Fotos teilen will.

Client

Die App, die Zugriff will. Die Foto-Druck-App im Beispiel.

Authorization Server

Der Aussteller der Tokens. Bei „Mit Google": accounts.google.com.

Resource Server

Die API mit den Daten. Bei Fotos: photoslibrary.googleapis.com.

In großen Systemen sind Authorization Server und Resource Server oft getrennt (so wie bei Google). In kleineren Setups ist es ein und derselbe Server. Wichtig in der Klausur: die Begriffe auseinanderhalten – „Resource Owner" ist nicht der Server, der die Ressource hat, sondern der Eigentümer, also der User. Verwirrend, aber Standard.

3) Der Authorization Code Flow live

Der häufigste OAuth2-Flow heißt Authorization Code Flow. Hier durchläufst du ihn Schritt für Schritt – klick „Weiter", um zu sehen, was passiert:

Authorization Code Flow durchklicken

Schritt 1: User klickt in der Foto-App auf „Mit Google anmelden".

Die Trennung in zwei Schritte (erst Auth-Code, dann Token gegen Code+Secret tauschen) ist kein Zufall: der Auth-Code wandert über den Browser des Users und ist kurzlebig + einmalig nutzbar. Der eigentliche Token-Tausch passiert direkt Server-zu-Server mit einem geheimen Client Secret, das der Browser nie sieht. So ist auch bei Abfangen des Codes (z.B. in Logs) der Token sicher.

4) Die Grant Types – verschiedene Flows für verschiedene Apps

OAuth2 definiert mehrere Grant Types – Varianten des Flows für unterschiedliche Client-Typen. Eine native Mobile-App braucht einen anderen Flow als ein Backend-Service. Hier die wichtigsten:

OAuth2 Grant Types

Authorization Code Standard für Web

Der oben durchgespielte Flow. Web-Apps mit Backend – Server kann das Client Secret sicher verwahren. Empfohlen für klassische Webanwendungen mit Server-Renderern.

Authorization Code + PKCE SPA / Mobile

PKCE = Proof Key for Code Exchange. Variante für Single-Page-Apps und Mobile-Apps, wo kein sicheres Client Secret möglich ist. Client erzeugt pro Login einen einmaligen Code-Verifier und schickt nur dessen Hash mit – schützt vor Code-Diebstahl.

Client Credentials Service-zu-Service

Keine User beteiligt. Ein Backend authentifiziert sich mit Client-ID und Secret und bekommt direkt einen Token. Typisch für Microservice-Kommunikation oder Server-Cronjobs.

Refresh Token verlängern

Kein eigenständiger Flow, sondern eine Ergänzung. Mit dem Refresh Token (langlebig) lässt sich ein neuer Access Token (kurzlebig) holen – ohne erneuten Login. Vgl. L5.

Implicit Flow veraltet ✗

Früher für SPAs gedacht – Token direkt im URL-Fragment. Heute abgekündigt (OAuth2.1) wegen Sicherheits-Schwächen. Stattdessen Authorization Code + PKCE.

Resource Owner Password veraltet ✗

App sammelt Username/Passwort direkt und tauscht es gegen Token. Verstößt gegen die Grundidee von OAuth2 (das Passwort soll die App nie sehen!). Nur noch in Migrations-Szenarien akzeptabel.

Faustregel für deine API: Authorization Code + PKCE ist heute der Standard für alle Client-Typen mit User-Beteiligung. Client Credentials für reine Service-Kommunikation. Die anderen Grant Types sind veraltet oder Spezialfälle. In modernen Standards (OAuth 2.1) sind Implicit und Password offiziell entfernt.

5) Scopes: granulare Berechtigungen

Eine der mächtigsten Eigenschaften von OAuth2 sind Scopes – feine Berechtigungs-Klassen. Statt „Vollzugriff" gibt der User der App nur das, was sie wirklich braucht. Wer kennt nicht den Google-Dialog: „Diese App möchte Zugriff auf: Lese deine E-Mail-Adresse, Sehe deine Fotos. Erlauben?"

Scope-Picker: wähle, was die App darf

profile:readName & Avatar lesen

email:readE-Mail-Adresse lesen

photos:readFotos ansehen

photos:writeFotos hochladen

calendar:readKalender lesen

Klick eine Berechtigung an, um den Token zu sehen ...

Beobachte: jede gewählte Berechtigung landet als String im scope-Feld des Token-Requests und später im Token selbst. Der Resource Server prüft bei jedem API-Call, ob der vorgewiesene Token den nötigen Scope hat. Wer mit photos:read einen DELETE /photos/42 aufruft, bekommt 403 Forbidden – richtige Authentifizierung, aber keine Berechtigung (vgl. L4 – 401 vs. 403).

6) OAuth2 vs. OpenID Connect – die wichtigste Unterscheidung

Eines der häufigsten Missverständnisse: OAuth2 ist keine Authentifizierung. Es ist Autorisierung. Das Access Token sagt: „dieser Client darf Fotos lesen" – nicht „der User ist Anna Müller". Strenggenommen weiß der Client gar nicht, wer der User ist. Genau diese Lücke schließt OpenID Connect (OIDC).

OAuth2 vs. OpenID Connect

OAuth 2.0

Autorisierung (was darf die App?)

Stellt Access Tokens aus. Die App kann damit APIs aufrufen, kennt aber die User-Identität nicht direkt. Antwortet auf: „Was darf der Client tun?" Beispiel: App holt Fotos aus Google Photos.

OpenID Connect

Authentifizierung + Identität

Erweitert OAuth2 um ein zusätzliches ID Token (ein JWT!). Enthält Claims wie Name, E-Mail, Avatar. Antwortet auf: „Wer ist der User?" Beispiel: „Mit Google anmelden" – die App erfährt, wer du bist.

Eselsbrücke: OAuth2 sagt was du darfst, OIDC sagt wer du bist. In der Praxis kommt fast nie OAuth2 allein, sondern OAuth2 + OIDC. Wenn du irgendwo „Mit Google / GitHub / Microsoft anmelden" anbietest, sprichst du OIDC. Wichtigste Erweiterung: das ID Token ist ein JWT mit standardisierten Claims (sub, name, email, picture) – siehe L5.

7) ID Token vs. Access Token – nicht verwechseln!

OIDC führt das ID Token als zusätzliches Token ein. Es wird oft mit dem Access Token verwechselt, hat aber einen anderen Zweck:

Access Token: für den Client gedacht, um APIs aufzurufen. Enthält Scopes. Der Client „benutzt" ihn nur. Beispiel: in einem Authorization: Bearer ...-Header an die Foto-API senden.
ID Token: für den Client gedacht, um den User zu kennen. Enthält Identitäts-Claims. Der Client „liest" ihn und zeigt z.B. „Hallo, Anna" im UI. Wird nicht an APIs gesendet.

Beide werden vom Authorization Server beim Login ausgestellt. Beide sind JWTs (im Falle von OIDC). Wer die zwei verwechselt und ID Tokens an APIs schickt, baut Sicherheitslücken – die API würde fälschlich „glauben", der User ist autorisiert.

8) Praktisches Beispiel: „Mit Google anmelden"

So implementierst du Login via Google in deiner Web-App – konzeptionell in fünf Schritten:

Bei Google Cloud Console registrieren: Client-ID + Secret erhalten, Redirect-URI hinterlegen.
In deiner App einen Button „Mit Google anmelden": Klick führt zu https://accounts.google.com/o/oauth2/v2/auth?client_id=...&scope=openid+email+profile&redirect_uri=...&response_type=code.
User loggt sich bei Google ein, gibt Zustimmung. Google leitet zurück zu deiner Redirect-URI mit Auth-Code.
Dein Backend tauscht den Code beim Token-Endpunkt gegen Access Token + ID Token (+ optional Refresh Token).
Aus dem ID Token (JWT!) liest dein Backend Name und E-Mail des Users, legt eine Session an, fertig.

Ergebnis: dein User muss bei dir kein Konto anlegen und kein Passwort merken. Du musst keine Passwörter speichern (siehe K11 Hashing). Win-win. In der Praxis nutzt man fertige Libraries wie passport (Node.js), django-allauth (Python), Spring Security OAuth (Java) – nie selbst implementieren.

9) Häufige Klausurfragen

Die vier Rollen nennen und erklären: Resource Owner, Client, Authorization Server, Resource Server.
Unterschied OAuth2 vs. OIDC: OAuth2 = Autorisierung (was darf die App?), OIDC = Authentifizierung (wer ist der User?) auf OAuth2 aufbauend.
Access Token vs. ID Token: Access für API-Calls, ID für die Identität des Users im Client.
Wann welcher Grant Type: Web mit Backend = Auth Code, SPA/Mobile = Auth Code + PKCE, Service-zu-Service = Client Credentials.
Warum 2-Schritte-Flow: Auth-Code geht über Browser (unsicher), Token-Tausch direkt Server-zu-Server (sicher).
Scopes: granulare Berechtigungen statt Vollzugriff, vom User explizit zugestimmt (Consent-Screen).

Zusammenfassung

OAuth 2.0 ist der Standard für delegierte Autorisierung: eine App bekommt eingeschränkten Zugriff auf User-Daten, ohne das Passwort zu kennen. Analogie: Hotel-Keycard. Vier Rollen: Resource Owner (User), Client (App), Authorization Server (stellt Tokens aus), Resource Server (hat die Daten). Authorization Code Flow ist der Standard-Flow: User loggt beim Auth-Server ein, gibt Consent, Client erhält Auth-Code, tauscht ihn server-seitig mit dem Client Secret gegen einen Access Token. Die Trennung in zwei Schritte schützt den Token vor Abfangen im Browser. Wichtige Grant Types: Authorization Code (Web), Code + PKCE (SPA/Mobile), Client Credentials (Service-zu-Service). Implicit und Password Grant sind veraltet. Scopes = granulare Berechtigungen (photos:read) – User stimmt explizit zu, Resource Server prüft sie. Fehlt der nötige Scope → 403 (vgl. L4). OAuth2 vs. OIDC: OAuth2 = Autorisierung („was darf die App?"). OpenID Connect ergänzt Authentifizierung („wer ist der User?") mit einem zusätzlichen ID Token (ein JWT). ID Token vs. Access Token: ID Token nur für Identität im Client, niemals an APIs senden. Klausur-Fokus: die vier Rollen, OAuth2 vs. OIDC, ID vs. Access Token, Grant-Type-Auswahl. Nächste Lektion: API-Versionierung.