OAuth 2.0

Jedes Mal, wenn ein Popup kommt: "App X möchte zugreifen auf: Kontakte, Kalender". Als Entwickler: Nutze Libraries (passport.js, Spring Security). Baue OAuth nie selbst (Security-Hölle). Unterscheide:

• Authorization Code Flow: Für Server-Apps (Sicher).
• PKCE (Pixie): Für Mobile/SPA Apps (Pflicht!).
• Implicit Flow: Veraltet und unsicher (Nicht mehr nutzen!).

Praxisroutine

In der Praxis lernst du OAuth 2.0, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Scopes

Der Kern der Sicherheit. scope="photos.read mail.send". Der User sieht genau, was er erlaubt. Der Token enthält diese Scopes (oft im JWT). Der Resource Server (API) prüft: "Hat der Token mail.send? Nein? 403 Forbidden."

2. Refresh Token

Access Tokens leben kurz (z. B. 15 Min). Damit der User sich nicht ständig neu einloggen muss, gibt es den Refresh Token (lebt z. B. 30 Tage). Mit dem Refresh Token kann die App neue Access Tokens holen. Der Refresh Token ist hochsensibel und muss extrem sicher gespeichert werden.

Technische Einordnung im System

Technisch ist OAuth 2.0 nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

1. PKCE (Proof Key for Code Exchange) Cryptology

Mobile Apps haben ein hartes Naturgesetz: Alles, was auf dem Smartphone läuft (Frontend), kann rück-ge-engineered werden! Beim normalen Authorization Code Flow für Server gibt es ein client_secret (ein Passwort), das der Server im Backend an den Auth Provider (Google) schickt, um den eigentlichen JWT zu generieren. Eine iOS App darf dieses Secret niemals im Quelltext tragen! Wie verhindert man nun, dass eine asiatische Malware-App sich in den Android-Browser Hook reinhakt (Deep Link Interception) und den begehrten authorization_code vom Google Callback stiehlt und ihn sofort einlöst? PKCE (IETF RFC 7636). Die Frontend App generiert beim Start flüchtig einen gigantischen Hash Zufall (code_verifier) und sendet beim Login nur dessen kryptografischen SHA-256 (code_challenge) mit. Wenn der Google Login klappt und die Malware den resultierenden Code aus der URL fischt, schlägt sie am API-Endpoint fehl. Um den Code in ein Token umzutauschen, verlangt der Server als Hard-Beweis exakt den originalen flüchtigen Klartext code_verifier, den NUR die originale erste App im Session-RAM hält! Mithin perfekter Schutz für Public Clients ohne Backend-Secret (SPA/Mobile).

2. State-Parameter & CSRF Token Injection

Ein verheerender Vektor beim OAuth ist der Login-Cross-Site Request Forgery (CSRF). Hacker Bob startet einen eigenen regulären OAuth Fluss bei Google. Er blockiert im Browser genau die letzte Millisekunde, bevor sein gestohlener code gegen seine echte Mail-ID eingelöst wird. Er kopiert diesen URL-Callback (https://deine-app.com/callback?code=Bobs_Böser_Code). Bob schickt diesen Link per Phishing an Opfer Alice. Alice klickt! Alices Browser übergibt unschuldig Bobs Code an DEINE App. Deine App tauscht den Code ein und verknüpft Alices offene Session-ID brutal mit Bobs-Google Account ("Login Forgery"). Bob hat sofort vollen Vollzugriff (!) auf Alices neu erstelltes Profil bei dir im SaaS. Die einzige Rettung: Der state Parameter. Beim Start injectet dein Backend einen Random State (Nonce) in Alices Session-Cookie. Beim Rücksprung checkt das Backend hart: $Url.state == $Cookie.state. Alices Session weist Bobs manipulierten HTTP-Link sofort als fremden Nonce unbarmherzig ab.

3. JWT Audience (aud) vs Scope Exploit

Access Tokens (in der Form von verschlüsselten/signierten JWTs) leiten ihr Limit oft durch Scopes wie user.read ab. Eines der größten architektonischen Leaks von Microservice-Parks ist das Ignorieren des Audience (aud) Claims. Stell dir vor, du baust Service A (Bilder-Dienst) und Service B (Banking-Dienst). Beide delegieren ans gleiche OAuth Portal. Ein Hacker loggt sich in Bilder-Dienst A legal ein und extrahiert seinen regulären JWT. Dieser JWT hat zufällig den globalen Scope read:all. Der Hacker feuert ihn an den Banking-Dienst API Endpoint B. Service B prüft nur die Signatur (korrekt) und Scope (korrekt, read:all) und dumpt die Banking Konten! Dieser fatalistische "Token Pivot" Bug (Confused Deputy) wird durch aud vernichtet! Der Bilder-Dienst Token muss intern eingebettet den Empfänger referenzieren: "aud": "api-gateway-pictures". Service B lehnt den valid signierten JWT sofort unerbittlich ab (401 Unauthorized), weil er explizit einen Token für die Audience "api-banking" verlangt.