OAuth

Du willst dich bei "Spotify" anmelden. Statt ein neues Passwort zu erfinden, klickst du "Login mit Facebook". Willst du Spotify dein Facebook-Passwort geben? Nein! (Spotify könnte sonst in deinem Namen posten). OAuth löst das. Du sagst Facebook: "Gib Spotify den Wohnungsschlüssel, aber nur für das Wohnzimmer (Musik), nicht fürs Schlafzimmer (Chat)." Spotify bekommt keinen Schlüssel (Passwort), sondern nur einen Token (Besucherausweis).

Merksatz: Ein offener Standard, der es Nutzern erlaubt, Drittanbietern Zugriff auf ihre Daten zu gewähren, ohne Passwörter weiterzugeben.

Das Fenster, das aufpoppt ("Zulassen, dass App X auf deine Kontakte zugreift?"), ist OAuth. Es gibt drei Parteien:

Du (Resource Owner).
Die App (Client, z. B. Spotify).
Der Service (Authorization Server, z. B. Facebook/Google).

Praxisroutine

In der Praxis lernst du OAuth, 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. Access Token vs. Refresh Token

Access Token: Der Ausweis. Damit holt Spotify deine Daten. Er ist nur kurz gültig (z. B. 1 Stunde). Wenn er geklaut wird, ist der Schaden begrenzt.
Refresh Token: Der "Joker". Wenn der Access Token abläuft, schickt Spotify den Refresh Token an Google: "Gib mir einen neuen Ausweis." Den muss man extrem sicher speichern.

2. OAuth vs. OpenID Connect (OIDC)

OAuth ist für Erlaubnis (Authorization): "Darf Spotify meine Playlist sehen?" OIDC ist für Identität (Authentication): "Wer bin ich?" Der "Login mit Google"-Button nutzt eigentlich OIDC (das auf OAuth aufbaut).

Technische Einordnung im System

Technisch ist OAuth 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. Authorization Code Grant Code (PKCE)

Eine rohe Mobile-App kann den App-Secret-Key nicht verbergen (Hacker dekompilieren APKs in Minuten). Damit fiele der klassische Oath2 Flow, bei dem der App-Server sein Secret an Google funken muss, um den Code gegen Tokens zu tauschen (Confidential Client), komplett in sich zusammen. Die moderne Lösung ist PKCE (Proof Key for Code Exchange). Die Mobile-App erzeugt beim Login-Klick lokal im Handy einen kryptografischen Zufallsschlüssel (Code Verifier) und schickt nur dessen Hash-Wert (Code Challenge) an Google. Google sendet den Auth-Code zurück ans Handy. Nun muss die App das finale AccessToken abholen und sendet als Beweis den unlesbaren, rohen Verifier mit. Google hasht diesen Verifier auf dem Server nochmal. Stimmt der Hash absolut überein, weiß Google unwiderlegbar: Der Client, der das Token fordert, ist derselbe, der vor drei Minuten per Fingerwisch eingeloggt wurde. Ein böse mitlesender Man-in-the-Middle geht leer aus, da er den Code, aber niemals den Verifier stiehlt.

2. Bearer Tokens und JWT Delegation

Das Access Token (der Besucherausweis) wird bei fast allen modernen APIs als roher Bearer Token im HTTP Header übermittelt (Authorization: Bearer ds89Adf...). "Bearer" heißt wörtlich "Überbringer" – dem Server ist völlig egal, ob du ein Google Desktop Client oder eine russische Phishing-Bande bist. Wer dieses String-Token präsentiert, gilt als legitimer Inhaber und erhält Admin-Rechte auf dem Account. Meistens (bei OIDC) steckt darinnen ein JSON Web Token (JWT), welches kryptografisch via ECDSA oder RS256 signiert ist und absolut dezentral vom Ziel-Server durch validieren des Google Public-Keys verifiziert werden kann, ohne Google bei jedem Request belästigen zu müssen.

3. Scopes und Principle of Least Privilege

OAuth brilliert bei Isolation. Eine App verlangt nicht einfach "Zugang". Sie sendet im Initial-Request einen scope Parameter (z.B. scope=read_calendar write_email). Der Authorization Server (Login Page) klärt den Enduser in dicker, roter Schrift auf, welche Berechtigungen gefordert sind. Best Practice ist incremental authorization. Die App fordert beim Login nur profile an (minimal invasiv, hohe User-Adoption-Rate). Erst in der Sekunde, bei der der User auf "Kalender jetzt synchronisieren" drückt, startet die App dynamisch einen zweiten OAuth Flow spezifisch aufgerüstet mit dem neuen Scope.