OAuth-2.0-Flows

OAuth 2.0 ist ein Framework für delegierte Autorisierung. Es ermöglicht einem Benutzer, einer Drittanbieteranwendung begrenzten Zugriff auf seine Ressourcen bei einem anderen Dienst zu gewähren, ohne sein Passwort weiterzugeben.

• Es geht um Autorisierung (was eine Anwendung tun darf), nicht um Authentifizierung (wer der Benutzer ist).
• Die Anwendung erhält ein scoped access_token, niemals die Zugangsdaten des Benutzers.

Für die Verteidigung gilt: OAuth allein weist keine Identität nach. Ein Access Token als Beleg für eine Anmeldung zu behandeln, ist ein klassischer Fehler, den OIDC behebt.

Jeder OAuth-Flow umfasst vier Rollen. Ihre korrekte Zuordnung ist für die Bedrohungsmodellierung unerlässlich.

• Ressourceninhaber – der Benutzer, dem die Daten gehören.
• Client – die Anwendung, die Zugriff anfordert.
• Autorisierungsserver (AS) – stellt nach der Zustimmung Tokens aus.
• Ressourcenserver (RS) – die API, die geschützte Daten enthält und Tokens validiert.

Zwischen diesen Rollen liegen Vertrauensgrenzen. Ein kompromittierter Client oder ein zu freizügiger AS gefährdet die gesamte Kette.

Der Authorization Code Grant ist der empfohlene Flow für Web- und Mobile-Anwendungen. Er trennt die benutzerseitige Weiterleitung vom geheimen Token-Austausch.

• Der Benutzer wird zum AS weitergeleitet, um sich zu authentifizieren und seine Zustimmung zu geben.
• Der AS gibt einen kurzlebigen code an die registrierte Redirect URI zurück.
• Der Client tauscht den Code serverseitig über einen Backchannel gegen Tokens aus.

Da die Tokens über den Backchannel abgerufen werden, erscheinen sie weder in der Adressleiste noch im Verlauf des Browsers.

PKCE (RFC 7636) erhöht die Sicherheit des Authorization Code Grant und wird inzwischen für alle Clients empfohlen, auch für vertrauliche.

• Der Client erzeugt einen zufälligen code_verifier und sendet dessen Hash als code_challenge.
• Beim Token-Austausch muss er den ursprünglichen Verifier vorlegen.

Dadurch wird der Code an den ursprünglichen Anfragesteller gebunden. Ein Angreifer, der den Authorization Code abfängt, kann ihn dadurch nicht einlösen.

Der Client Credentials Grant ist für den Machine-to-Machine-Zugriff vorgesehen, bei dem kein Benutzer beteiligt ist, etwa wenn ein Backend-Dienst eine API aufruft.

• Der Client authentifiziert sich mit seinen eigenen Zugangsdaten und erhält ein Access Token.
• Es gibt keine Zustimmung des Benutzers und in der Regel kein Refresh Token.

Begrenzen Sie den Geltungsbereich dieser Tokens strikt und wechseln Sie Client Secrets regelmäßig. Verwenden Sie diesen Flow niemals, um Endbenutzer zu imitieren.

OAuth stellt zwei wichtige Tokentypen mit sehr unterschiedlichen Gültigkeitsdauern und Regeln für ihre Handhabung aus.

• Access Token – kurzlebig, wird bei jedem Aufruf an den Ressourcenserver gesendet. Behandeln Sie es als Bearer-Zugangsdaten.
• Refresh Token – langlebig, wird nur gegenüber dem AS verwendet, um neue Access Tokens abzurufen.

Refresh Tokens sind besonders wertvoll. Speichern Sie sie sicher, binden Sie sie an den Client und unterstützen Sie ihren Widerruf.

Die meisten OAuth-Access-Tokens sind Bearer-Tokens: Wer das Token besitzt, kann es verwenden – ähnlich wie Bargeld.

• Übertragen Sie sie immer über TLS, niemals in URLs, wo sie in Logs und Referrern offengelegt werden.
• Senden Sie sie über den Authorization-Header.
• Ziehen Sie für APIs mit hohem Risiko sendergebundene Tokens (DPoP, mTLS) in Betracht.

Der veraltete Implicit-Grant gab Tokens direkt im Fragment der Redirect-URI zurück. Er wird inzwischen vom OAuth 2.0 Security BCP nicht empfohlen und wurde aus OAuth 2.1 entfernt.

• Tokens wurden über den Browserverlauf, Referrer-Header und Logs offengelegt.
• Ohne Backchannel war die Client-Authentifizierung schwächer.

Verwenden Sie stattdessen Authorization Code with PKCE für SPAs.

Der state-Parameter schützt den Redirect-Schritt vor CSRF. Der Client erzeugt einen zufälligen Wert, speichert ihn in der Sitzung und überprüft ihn beim Callback.

• Wenn der zurückgegebene state nicht übereinstimmt, lehnen Sie die Antwort ab.
• Dadurch wird verhindert, dass ein Angreifer seinen eigenen Authorization Code in eine Opfersitzung einschleust.

Scopes geben die Granularität des Zugriffs an, den ein Token gewährt. Wenden Sie das Prinzip der geringsten Berechtigung bei jedem Schritt an.

• Fordern Sie nur die Scopes an, die das Feature benötigt (read:profile, nicht admin).
• Ressourcenserver müssen den Scope an jedem Endpunkt erzwingen und dürfen nicht nur einem gültigen Token vertrauen.

Zu weit gefasste Einwilligungen sind ein häufiges reales Risiko: Benutzer genehmigen Apps, die deutlich mehr Berechtigungen anfordern als erforderlich.

Die meisten OAuth-Vorfälle sind auf die Konfiguration und nicht auf das Protokoll selbst zurückzuführen.

• Open Redirect / zu lockerer Abgleich von redirect_uri ermöglicht es Angreifern, Codes zu stehlen.
• Fehlendes state oder PKCE ermöglicht CSRF und das Einschleusen von Codes.
• Langlebige Access-Tokens ohne Widerrufsmöglichkeit.
• Ein Access-Token wird als Authentifizierungsnachweis behandelt.

Registrieren Sie exakte Redirect-URIs und validieren Sie sie strikt.

Wählen Sie für das folgende Szenario den korrekten modernen Flow.

Die wichtigsten Punkte:

• OAuth 2.0 ist eine delegierte Autorisierung, keine Authentifizierung.
• Vier Rollen: Ressourcenbesitzer, Client, Authorization Server und Ressourcenserver.
• Authorization Code + PKCE ist der Standard für Webanwendungen, mobile Anwendungen und SPAs.
• Client Credentials deckt den Zugriff zwischen Maschinen ab.
• Schützen Sie Ihre Anwendung mit state, einem strikten Abgleich der Redirect-URI, kurzlebigen Access-Tokens und TLS an jeder Stelle.
• Implicit- und Password-Grants sind veraltet.