OAuth 2.0.

OAuth 2.0 (RFC 6749) trennt vier Rollen: den Ressourceninhaber (Benutzer), den Client (Anwendung), den Autorisierungsserver, der Tokens ausstellt, und den Ressourcenserver, der die API bereitstellt. Der Client erhält ein Access Token über einen definierten Grant – Authorization Code mit PKCE (RFC 7636) für interaktive Apps, Client Credentials für Service-zu-Service-Aufrufe, Device Code (RFC 8628) für Geräte mit eingeschränkter Eingabemöglichkeit – und ruft anschließend die API mit diesem Token als Bearer-Credential auf. Scopes und Audiences grenzen ein, was das Token darf.

Sicherheitsempfehlungen und Fallstricke

RFC 9700 (BCP 240, veröffentlicht im Januar 2025) fasst die OAuth-Sicherheitspraxis zusammen: Es erklärt den Implicit Grant und den Resource-Owner-Password-Credentials-Grant für veraltet, schreibt PKCE für jeden Authorization-Code-Client vor und verlangt exaktes Redirect-URI-Matching, um Code-Interception- und Open-Redirect-Angriffe abzuwehren. Da Access Tokens Bearer-Credentials sind, begrenzt eine Sender-Bindung mittels DPoP oder Mutual-TLS den Replay nach einem Diebstahl.

Der dominierende Missbrauch in der Praxis ist OAuth-Consent-Phishing (illegitime Zustimmungserteilung): Statt Passwörter zu stehlen, registrieren Angreifer eine bösartige App und verleiten Benutzer dazu, weitreichende Scopes zu genehmigen. Der „Google Docs"-Wurm vom Mai 2017 verbreitete sich auf diese Weise in etwa einer Stunde, und APT29/Nobelium missbrauchten wiederholt Microsoft-365-Zustimmungserteilungen, um MFA zu umgehen und dauerhaft Zugriff zu behalten. Zu den Gegenmaßnahmen zählen Admin-Consent-Workflows, Publisher-Verifizierung, kurzlebige Tokens und das Widerrufen ungenutzter Zustimmungen.

flowchart LR
  U[Ressourceninhaber] -->|1 autorisieren + code_challenge| AS[Autorisierungsserver]
  AS -->|2 Auth-Code per Redirect| C[Client-App]
  C -->|3 Code + code_verifier| AS
  AS -->|4 Access Token| C
  C -->|5 Bearer Token| RS[Ressourcenserver / API]
  RS -->|6 geschützte Daten| C