Warum Begriffe bei OAuth entscheidend sind
OAuth ist berüchtigt dafür, kompliziert und unübersichtlich zu wirken. Viele Artikel werfen mit Begriffen wie Access Token, Authorization Code oder Client um sich, ohne sie klar abzugrenzen. Genau das führt dazu, dass Entwickler Fehler machen oder Sicherheitsprüfer nicht wissen, wo sie ansetzen sollen.
In diesem Teil nehmen wir die zentralen Bausteine auseinander und ordnen sie so, dass man später versteht, wie Angriffe wie Token-Diebstahl, CSRF oder Open Redirects überhaupt möglich sind.
Die vier Hauptrollen in OAuth
1. Ressourcen-Eigentümer (Resource Owner)
Das bist du – der Benutzer.
- Du besitzt die Daten, die geschützt sind, z. B. deine E-Mails, Fotos oder Kalendereinträge.
- Du entscheidest, ob eine andere Anwendung im deinem Namen auf diese Daten zugreifen darf.
👉 Analogie: Du bist Hotelgast. Dein Zimmer ist deine Ressource.
2. Client (die Anwendung, die Zugriff will)
Das ist die App oder Webseite, die etwas für dich erledigen möchte.
- Beispiel: Eine Fitness-App will auf deine Spotify-Playlisten zugreifen.
- Der Client darf niemals dein Passwort kennen. Er bekommt nur eine Art „Schlüssel“ (Token), um das Nötigste zu erledigen.
👉 Analogie: Die Reinigungsfirma, die in dein Hotelzimmer darf – aber nicht in den Safe oder in die Zimmer anderer Gäste.
3. Ressourcen-Server (Resource Server)
Hier liegen die geschützten Daten.
- Beispiel: Die API von Google, die deine Kontakte oder Kalenderdaten bereitstellt.
- Der Ressourcen-Server prüft jedes Mal, ob das mitgelieferte Token gültig und ausreichend ist.
👉 Analogie: Der Türsteher vor dem Hotelzimmer, der nur Schlüssel akzeptiert, die der Hotelmanager ausgestellt hat.
4. Autorisierungs-Server (Authorization Server)
Das ist die Stelle, die dich einloggt und die Tokens ausstellt.
- Beispiel:
accounts.google.comprüft dein Passwort, zeigt dir die Einwilligungs-Seite („Diese App möchte deine E-Mails lesen“) und stellt dann Tokens aus. - Ohne Autorisierungs-Server gäbe es keine sichere Trennung zwischen dir und dem Client.
👉 Analogie: Der Hotelmanager, der Schlüssel verwaltet, Buch führt und neue Schlüssel ausgibt.
Tokens – die Schlüssel in OAuth
Tokens sind das Herzstück von OAuth. Sie bestimmen, wer was darf – und sind damit auch das Hauptziel von Angreifern.
1. Autorisierungscode (Authorization Code)
- Ein kurzlebiger Einmal-Code.
- Wird nach erfolgreichem Login ausgegeben, bevor der Client das eigentliche Token erhält.
- Muss gegen ein Access Token eingetauscht werden.
👉 Analogie: Ein Papierzettel vom Hotelmanager, den die Reinigungsfirma an der Rezeption vorzeigen muss, um den echten Schlüssel zu bekommen.
2. Zugangstoken (Access Token)
- Der eigentliche Schlüssel, mit dem der Client beim Ressourcen-Server arbeiten darf.
- Hat ein Ablaufdatum (z. B. eine Stunde).
- Enthält Informationen: Für welchen Nutzer? Für welche Berechtigungen (Scopes)?
👉 Analogie: Der Schlüssel, der ins Hotelzimmer passt – aber nur solange er gültig ist.
3. Aktualisierungs-Token (Refresh Token)
- Ein langlebigeres Token, das dazu dient, neue Access Tokens anzufordern.
- Vorteil: Der Nutzer muss sich nicht ständig neu einloggen.
- Risiko: Wenn ein Refresh Token gestohlen wird, kann ein Angreifer sehr lange Zugriff behalten.
👉 Analogie: Der Generalschlüssel beim Hotelmanager, mit dem er dir immer wieder neue Zimmerschlüssel ausstellen kann.
4. Identitäts-Token (ID Token, nur bei OIDC)
- Enthält Infos über dich selbst, z. B. Name, E-Mail.
- Wird genutzt, um Login-Funktionalität umzusetzen.
- Technisch meistens ein JWT (JSON Web Token).
👉 Analogie: Dein Ausweis, den du im Hotel vorzeigst.
Wichtige Parameter in OAuth
Redirect URI
Die Adresse, an die der Nutzer nach erfolgreicher Autorisierung zurückgeschickt wird.
- Muss exakt konfiguriert sein.
- Unsichere Wildcards oder offene Redirects sind eine der größten Schwachstellen.
👉 Beispiel:
https://example.com/oauth/callback
State
Ein zufälliger Wert, den die Anwendung mitschickt und beim Rückruf überprüft.
- Schützt vor CSRF-Angriffen.
- Wenn nicht vorhanden oder nicht geprüft, kann ein Angreifer OAuth-Flows übernehmen.
👉 Analogie: Ein Stempel auf dem Hotelschein, damit niemand eine Kopie fälschen kann.
Scope
Bestimmt, welche Rechte ein Token hat.
- Beispiel:
scope=email profile→ darf nur E-Mail-Adresse und Profil lesen. - Faustregel: So wenig Rechte wie nötig.
👉 Analogie: Ein Schlüssel, der nur die Zimmertür öffnet, aber nicht den Safe.
Response Type
Legt fest, was der Autorisierungs-Server zurückschickt.
code→ sicherer Autorisierungscode.token→ direktes Access Token (unsicher, alt).id_token→ Identitätsinformationen.
PKCE (Proof Key for Code Exchange)
Ein Sicherheitsmechanismus, um abgefangene Autorisierungscodes nutzlos zu machen.
- Vor allem für mobile Apps und Single-Page-Anwendungen gedacht.
- Verhindert „Code Injection“-Angriffe.
👉 Analogie: Ein zusätzlicher Zahlencode am Schlüssel, den nur die berechtigte Person kennt.
Zusammenspiel der Begriffe – ein kurzer Ablauf
- Du klickst auf „Mit Google anmelden“.
- Der Client leitet dich zum Autorisierungs-Server (Google).
- Du gibst dein Passwort ein und stimmst zu.
- Der Autorisierungs-Server gibt einen Code zurück.
- Der Client tauscht diesen Code gegen ein Access Token.
- Mit dem Token fragt der Client beim Ressourcen-Server deine Daten ab.
- Nach Ablauf des Tokens kann mit einem Refresh Token ein neues geholt werden.
Häufige Missverständnisse
- „OAuth = Login.“
Nein, OAuth ist für Autorisierung da. Login wird erst mit OpenID Connect korrekt umgesetzt. - „Access Token = Passwort.“
Nein, Tokens sind temporär, können widerrufen werden und gelten nur für bestimmte Aktionen. - „Scopes sind unwichtig.“
Doch, sie sind entscheidend: Ein falscher Scope kann zu weitreichendem Missbrauch führen. - „State ist optional.“
Nein, ohne State ist der Flow anfällig für CSRF.
Schreibe einen Kommentar