OAuth 2.0 ist ein von der IETF standardisiertes Autorisierungsframework. Es ermöglicht einem Client, mit Zustimmung eines Resource Owners begrenzten Zugriff auf einen HTTP-Dienst zu erhalten oder in definierten Szenarien im eigenen Namen auf Ressourcen zuzugreifen.
Was ist OAuth 2.0?
Eine Anwendung soll auf Daten eines anderen Dienstes zugreifen. Früher bedeutete das häufig: Der Nutzer gibt der Anwendung Benutzername und Passwort des fremden Dienstes. OAuth 2.0 trennt diese Rollen und ermöglicht stattdessen delegierte Berechtigungen.
RFC 6749 definiert OAuth 2.0 als Autorisierungsframework, mit dem eine Drittanwendung begrenzten Zugriff auf einen HTTP-Dienst erhalten kann. Das zentrale Wort ist Autorisierung: OAuth regelt, was eine Anwendung tun darf.
Die wichtigsten Rollen
- Resource Owner: die Instanz, die Zugriff erlauben kann – häufig der Nutzer.
- Client: die Anwendung, die Zugriff benötigt.
- Authorization Server: prüft die Autorisierung und stellt Tokens aus.
- Resource Server: stellt die geschützte API oder Ressource bereit.
Wie ein typischer Authorization Code Flow aussieht
Der Nutzer wird zum Authorization Server geleitet, stimmt dem Zugriff zu, der Client erhält einen kurzlebigen Authorization Code und tauscht diesen anschließend gegen ein Access Token. Mit diesem Token ruft der Client die freigegebene API auf.
Das Access Token ist dabei keine Kopie des Nutzerpassworts. Es kann zeitlich begrenzt und auf bestimmte Berechtigungen zugeschnitten sein.
OAuth ist nicht automatisch Login
Eine häufige Verwechslung: OAuth 2.0 definiert Autorisierung, nicht die Identität eines Nutzers. Für standardisierte Authentifizierung auf Basis von OAuth wird häufig OpenID Connect eingesetzt. Dabei liefert ein ID Token Informationen über die authentifizierte Identität.
PKCE ist heute ein zentraler Sicherheitsbaustein
Die Sicherheitslandschaft hat sich seit RFC 6749 weiterentwickelt. RFC 9700 dokumentiert aktuelle Best Practices und empfiehlt PKCE auch über den ursprünglichen Mobile-App-Anwendungsfall hinaus. PKCE bindet den Authorization Code an einen zuvor erzeugten geheimen Wert und erschwert dadurch den Missbrauch abgefangener Codes.
Veraltete Flow-Varianten sollten deshalb nicht einfach aus älteren Tutorials übernommen werden.
Scopes: so viel Zugriff wie nötig
OAuth kann Berechtigungen über Scopes begrenzen. Eine Anwendung könnte beispielsweise Leserechte auf Kalenderdaten erhalten, ohne Termine löschen zu dürfen.
Ein Kundenportal benötigt möglicherweise nur orders:read, während eine interne Administrationsanwendung zusätzlich orders:write erhält. Diese Trennung reduziert unnötige Rechte.
Typische Sicherheitsfehler
- Redirect URIs werden zu großzügig akzeptiert.
- Tokens landen in Logs oder URLs.
- Scopes sind unnötig weit gefasst.
- Refresh Tokens werden unzureichend geschützt.
- OAuth wird mit Authentifizierung verwechselt.
OAuth in Unternehmensintegrationen
OAuth 2.0 begegnet Entwicklern häufig bei APIs von SaaS-Diensten, Identitätsplattformen und Cloud-Anwendungen. Für Integrationen ist deshalb nicht nur die Implementierung des Protokolls relevant, sondern auch Token-Lifecycle, Rechtekonzept und sichere Speicherung.
Client Credentials für Maschine-zu-Maschine-Kommunikation
Nicht jeder OAuth-Vorgang betrifft einen interaktiven Nutzer. Bei Server-zu-Server-Integrationen kann ein Client im eigenen Namen auf eine Ressource zugreifen. Dafür existiert unter anderem der Client-Credentials-Grant.
Auch hier gilt das Prinzip minimaler Rechte. Ein technischer Client für einen nächtlichen Datenexport benötigt möglicherweise nur lesenden Zugriff auf einen eng begrenzten API-Bereich. Eigene Credentials pro Integration erleichtern spätere Sperrung, Rotation und Auditierung.
Fazit
OAuth 2.0 schafft ein standardisiertes Modell für delegierte Autorisierung. Der große Vorteil liegt darin, Zugangsdaten nicht an jede integrierte Anwendung weiterzugeben und Rechte gezielt begrenzen zu können. Moderne Implementierungen sollten sich allerdings nicht nur an RFC 6749, sondern auch an den aktuellen Security Best Practices aus RFC 9700 orientieren.
Passende Leistungen von Wils Solutions
Häufige Fragen
Ist OAuth 2.0 ein Login-Protokoll?
OAuth 2.0 ist primär ein Autorisierungsframework. Für standardisierte Authentifizierung wird häufig OpenID Connect auf Basis von OAuth 2.0 verwendet.
Was ist ein Access Token?
Ein Access Token ist eine Berechtigung, mit der ein Client auf geschützte Ressourcen zugreifen kann. Form und Inhalt sind nicht durch OAuth 2.0 auf ein einziges Tokenformat festgelegt.
Was ist PKCE?
PKCE bindet den Authorization Code kryptografisch an den Client-Vorgang und schützt insbesondere vor dem Missbrauch abgefangener Authorization Codes.
Was ist ein Scope?
Ein Scope beschreibt den angeforderten oder gewährten Berechtigungsumfang, beispielsweise nur lesenden Zugriff auf bestimmte API-Funktionen.