OAuth 2.0

OAuth 2.0 ist das Standardprotokoll für delegierte Autorisierung – es lässt eine Drittanbieter-Anwendung auf Ressourcen zugreifen, die Sie bei einem anderen Dienst kontrollieren, ohne Ihr Passwort herauszugeben. „Mit Google anmelden“, „Verbinde dein GitHub-Konto“, „Gewähre Zapier Zugriff auf dein Gmail“ – all das nutzt OAuth.

Die vier Rollen: Resource Owner (der Nutzer), Client (die Drittanbieter-App), Authorization Server (der OAuth-ausstellende Dienst, z. B. accounts.google.com), Resource Server (die API, die der Client aufrufen will, z. B. gmail.googleapis.com).

Der häufigste Ablauf (Authorization Code mit PKCE):

1. Der Client leitet den Nutzer zum Auth-Server weiter.
2. Der Nutzer meldet sich an und genehmigt die angeforderten Scopes.
3. Der Auth-Server leitet mit einem einmaligen Autorisierungscode zurück.
4. Der Client tauscht den Code (plus PKCE-Verifier) gegen ein Zugriffstoken.
5. Der Client ruft den Resource Server mit dem Zugriffstoken auf.

OAuth 2.0 dient nur der Autorisierung. OpenID Connect (OIDC) ist die Authentifizierungsschicht darüber – sie ergänzt ein ID-Token (ein JWT mit Claims darüber, wer der Nutzer ist), sodass der Client weiß, wer sich angemeldet hat, und nicht nur „irgendein autorisierter Nutzer“. Die meisten modernen „Mit X anmelden“-Abläufe sind OIDC, nicht reines OAuth.

Warum PKCE für öffentliche Clients inzwischen verpflichtend ist: Der ursprüngliche OAuth-2.0-Authorization-Code-Flow ging davon aus, der Client könne ein Geheimnis bewahren. Mobile Apps und Single-Page-Apps können das nicht – jeder kann die App disassemblieren und das eingebettete Geheimnis extrahieren. PKCE (Proof Key for Code Exchange, RFC 7636) ersetzt das statische Client-Geheimnis durch einen zufälligen Verifier pro Ablauf, der per SHA-256 gehasht wird: Der Client sendet den Hash vorab und gibt den Klartext erst beim Einlösen des Codes preis, womit er beweist, dass er derselbe Client ist, der den Ablauf gestartet hat. PKCE ist nun für alle öffentlichen Clients erforderlich (OAuth 2.1, RFC 9700 BCP) und wird zur Tiefenstaffelung auch für vertrauliche Clients empfohlen.

Die vier Abläufe, die Sie kennen sollten, und die zwei, die Sie meiden sollten: Verwenden Sie Authorization Code + PKCE für nahezu alles (Web, Mobile, SPA). Verwenden Sie Client Credentials für Maschine-zu-Maschine-API-Aufrufe, bei denen kein Nutzer anwesend ist. Der Implicit-Flow (gibt Zugriffstoken direkt in URL-Fragmenten zurück) und der Resource Owner Password Credentials-Flow (der Client sammelt das Passwort direkt ein) sind beide in OAuth 2.1 veraltet – keiner schützt angemessen gegen moderne Angriffe. Jede neue OAuth-Integration sollte sie ablehnen, selbst wenn ein Anbieter sie anbietet. Verwandt: JWT, SAML. Referenz: RFC 6749 — OAuth 2.0, RFC 7636 — PKCE.

Durchgerechnetes Beispiel

Eine Schaltfläche „Slack verbinden“ in Ihrem SaaS löst eine Weiterleitung aus zu https://slack.com/oauth/v2/authorize?client_id=...&scope=chat:write,channels:read&redirect_uri=https://app.example.com/oauth/callback&state=xyz&code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256. Der Nutzer genehmigt; Slack leitet weiter zu https://app.example.com/oauth/callback?code=ONE_TIME_CODE&state=xyz. Ihr Backend sendet einen POST an https://slack.com/api/oauth.v2.access mit dem Code, dem ursprünglichen PKCE-Verifier und der Client-ID. Slack gibt zurück: {"access_token": "xoxb-...", "scope": "chat:write,channels:read", "team": {"id": "T123"}}. Sie speichern das Zugriffstoken serverseitig (niemals im Local Storage des Browsers) und verwenden es als Authorization: Bearer xoxb-... bei späteren Slack-API-Aufrufen. Der gesamte Austausch dauert einige hundert Millisekunden; der Nutzer sieht einen Zustimmungsbildschirm und tippt nie ein Slack-Passwort in Ihre App.

Wann und warum es zählt

OAuth-Fehlkonfigurationen gehören zu den am häufigsten ausgenutzten Kategorien in der modernen Web-Sicherheit. Häufige Fehlermuster: den state-Parameter nicht zu validieren (ermöglicht CSRF auf dem Callback), Platzhalter bei der redirect_uri-Registrierung zuzulassen (ermöglicht Token-Diebstahl per Open-Redirect), Zugriffstoken in browserzugänglichem Speicher abzulegen (XSS-Exfiltration) und Refresh-Token als langlebige Bearer-Token zu behandeln, statt sie bei Verwendung zu rotieren. Die OAuth 2.0 Security Best Current Practice (RFC 9700, veröffentlicht 2025) kodifiziert die modernen Standardwerte: PKCE überall, exakt übereinstimmende Redirect-URIs, sender-gebundene Token (DPoP oder mTLS) für hochwertige APIs und Refresh-Token-Rotation mit Wiederverwendungserkennung. Wer dies befolgt, verwandelt die meisten OAuth-Pentest-Befunde in Nicht-Probleme. Referenz: RFC 9700 — OAuth 2.0 Security BCP.