OAuth-2.0-Flows und Tokentypen

OAuth 2.0 definiert vier Rollen. Der Resource Owner ist der Benutzer, dem die Daten gehören, beispielsweise die Dateien in seinem Google Drive. Der Client ist die Anwendung, die Zugriff anfordert. Der Authorization Server stellt Access Tokens aus, beispielsweise der OAuth-Server von Google. Der Resource Server hostet die geschützten Daten, beispielsweise die Google Drive API. Das Verständnis dieser Rollen macht den Zweck der einzelnen Flows deutlich.

Der Authorization-Code-Flow ist der richtige Flow für serverseitige Webanwendungen. Der Benutzer authentifiziert sich beim Authorization Server, der den Client anschließend mit einem kurzlebigen Authorization Code zurückleitet. Der Server des Clients tauscht diesen Code über eine Back-Channel-Anfrage gegen Tokens ein. Tokens gelangen niemals durch den Browser, wodurch sie vor Einträgen im Browserverlauf und dem Auslaufen über den Referrer geschützt sind.

Der Implicit Flow wurde für reine browserbasierte JavaScript-Anwendungen entwickelt, die Client-Secrets nicht sicher speichern konnten. Tokens wurden direkt im URL-Fragment zurückgegeben und umgingen den Back-Channel. Der Implicit Flow ist in OAuth 2.1 veraltet, da PKCE (RFC 7636) Public Clients ermöglicht, den Authorization-Code-Flow auch ohne Client-Secret sicher zu verwenden.

Der ROPC-Flow ermöglicht es Clients, den Benutzernamen und das Passwort des Benutzers direkt zu erfassen und gegen Tokens einzutauschen. Er war für besonders vertrauenswürdige First-Party-Clients vorgesehen, verfehlt jedoch grundsätzlich den Zweck von OAuth, Anwendungen den Zugriff auf Benutzeranmeldedaten zu verwehren. Er ist in OAuth 2.1 veraltet und sollte in keiner neuen Anwendung verwendet werden.

Der Client-Credentials-Flow ist für die Machine-to-Machine-(M2M-)Authentifizierung vorgesehen, bei der kein Benutzer beteiligt ist. Der Client authentifiziert sich direkt beim Authorization Server mit seiner Client-ID und seinem Client-Secret und erhält ein Access Token zur eigenen Verwendung. Häufige Anwendungsfälle sind Hintergrundaufgaben, die Kommunikation zwischen Microservices sowie API-Gateways, die auf Backend-Dienste zugreifen.

Der Device-Authorization-Flow (RFC 8628) ermöglicht OAuth auf Geräten mit eingeschränkten Eingabemöglichkeiten, etwa Smart-TVs, Spielekonsolen, Druckern und IoT-Geräten. Das Gerät zeigt einen kurzen Code und eine URL an. Der Benutzer besucht die URL auf einem Smartphone oder Computer, um die Autorisierung zu erteilen. Das Gerät fragt den Authorization Server wiederholt ab, bis der Benutzer die Autorisierung abgeschlossen hat.

OAuth 2.0 definiert zwei Arten von Access Tokens. Opake Tokens sind zufällige Zeichenfolgen, die der Resource Server validiert, indem er den Introspection-Endpunkt des Authorization Servers aufruft. JWT-Access-Tokens sind in sich geschlossen: Der Resource Server kann sie lokal durch Überprüfung der Signatur validieren. Dadurch werden weniger Introspection-API-Aufrufe benötigt, allerdings ist Schlüsselverwaltung erforderlich.

Refresh Tokens sind langlebige Anmeldedaten, mit denen nach Ablauf des Access Tokens neue Access Tokens angefordert werden. Bei der Refresh-Token-Rotation, die in OAuth 2.1 für Public Clients erforderlich ist, wird bei jeder Verwendung ein neues Refresh Token ausgestellt und das alte ungültig gemacht. Wird ein gestohlenes Refresh Token verwendet, erkennt der rechtmäßige Client die Ungültigkeit, wodurch sich der Token-Diebstahl erkennen lässt.

RFC 7662 definiert den Token-Introspection-Endpunkt. Über ihn können Resource Server den Authorization Server zum aktuellen Status (active/inactive), Scope, Subject und Ablaufzeitpunkt eines opaken Access Tokens abfragen. Introspection ermöglicht den sofortigen Widerruf von Tokens: Sobald ein Token beim Authorization Server widerrufen wurde, geben Introspection-Aufrufe unmittelbar active: false zurück.

RFC 7009 definiert den Token-Widerrufs-Endpunkt, über den Clients den Authorization Server darüber informieren können, dass ein Token (Access Token oder Refresh Token) ungültig gemacht werden soll. Dies wird beim Abmelden oder bei verdächtigen Aktivitäten verwendet. JWT-Access-Tokens können ohne eine Widerrufsliste nicht vollständig widerrufen werden, da Resource Server sie lokal validieren, ohne den Authorization Server zu kontaktieren.

OAuth-2.0-Scopes definieren die konkreten Berechtigungen, die der Client anfordert. Der Authorization Server legt dem Benutzer die angeforderten Scopes zur Genehmigung vor. Resource Server setzen die Scope-Anforderungen für jeden Endpunkt durch. Es gilt das Prinzip der geringsten Berechtigung: Clients sollten nur die benötigten Scopes anfordern, und Resource Server sollten Anfragen mit unzureichendem Scope ablehnen.

Welcher OAuth-2.0-Flow eignet sich für ein CLI-Tool oder IoT-Gerät, das einen Benutzer authentifizieren muss, aber keinen Browser und keine Tastatur besitzt?

Der Authorization-Code-Flow ist für serverseitige Anwendungen geeignet. Der Implicit Flow ist veraltet (verwenden Sie stattdessen PKCE). Der ROPC-Flow ist veraltet, da er den Zweck von OAuth zunichtemacht. Der Client-Credentials-Flow dient der M2M-Kommunikation. Die Device Authorization eignet sich für Geräte mit eingeschränkten Eingabemöglichkeiten. Access Tokens sind opak oder JWTs. Refresh Tokens sollten rotiert werden. Introspection (RFC 7662) und Widerruf (RFC 7009) vervollständigen das Token-Management.