Dieser Artikel gibt einen Einblick in verschiedene OAuth 2.0 Flows, deren Eigenschaften und welcher Flow sich am besten für welche Art von Applikation eignet. Die Grundlagen von OAuth 2.0 und ein Überblick zu SAML 2.0, OpenID Connect und dessen Unterschiede werden bereits im Artikel SAML 2.0, OpenID Connect, OAuth 2.0 erläutert. Wem nicht geläufig ist, ob OAuth nun Authentisierung oder Autorisierung ist, sollte zuerst dort vorbeischauen. Dieser Artikel fokussiert sich auf OAuth 2.0 gemäss RFC 6749 und geht dabei nicht auf andere erweiternde RFCs bezüglich OAuth 2.0 ein.

Nachfolgend ist mit OAuth immer OAuth 2.0 gemeint, sofern nicht explizit eine andere Version referenziert wird. Die Grundidee hinter OAuth ist fremden Applikationen autorisierter Zugriff zu ermöglichen, ohne dabei eine Kopie der Zugangsdaten von den Benutzern zu besitzen und die Benutzer selbst authentifizieren zu müssen. Durch OAuth lässt sich ebenfalls steuern was die fremde Applikation einsehen darf und für wie lange. Zudem kann der Zugriff pro Applikation widerrufen werden.

Begrifflichkeiten

Die OAuth 2.0 Spezifikation stellt verschiedene OAuth Prozesse, sogenannte Flows zur Verfügung. Durch die Angabe von grant_type beim Initiieren, wird der Flow festgelegt und nach dessen Schema durchgeführt.

Akteure

Eine Übersicht der vorkommenden Akteure in den verschiedenen OAuth Abläufen:

Fachbegriffe

Unterschiedliche Clienttypen

• Confidential: Clients, welche ihre Zugangsdaten sicher aufbewahren können. Der Client befindet sich auf einem sicheren Server mit eingeschränktem Zugriff auf Zugangsdaten oder kann sich auf eine andere sichere Art authentifizieren. Als Beipsiel gilt hier eine Webapplikation, welche die Client Zugangsdaten auf dem Webserver sicher vor Fremdzugriffen speichert.
• Public: Clients, welche ihre Zugangsdaten nicht sicher aufbewahren können. Dies bedeutet, der Resource Owner oder andere Drittparteien haben Zugriff auf die Zugangsdaten des Clients. Dies tritt hauptsächlich bei clientseitigen Implementierungen oder bei nativen Applikationen, welche sich auf einem Gerät des Resource Owners befinden, auf. Clientseitige Applikationen im Browser zählen wir hier als Beispiel auf. Hierbei wird die Applikation von einem Webserver in den Browser heruntergeladen und läuft dort. Diese Applikationen bestehen oft aus JavaScript, Progressive Web Apps (PWA) gehören auch zu dieser Kategorie. Native Applikationen, welche auf dem Gerät des Resource Owners installiert werden, ebenfalls.

OAuth Flows

Der folgende abstrakte Ablauf dient zum allgemeinen Verständnis des OAuth Prozesses, die verschiedenen Flows unterscheiden sich davon.

Abstrakter OAuth Ablauf

1. Der Client fragt den Zugriff auf Ressource X bei dessen Resource Owner an.
2. Der Resource Owner gewährt dem Client Zugriff (in Form eines Authorization Grant) auf die angefragten Ressourcen. Dies geschieht in Form des zwischen Client und OAuth Service Provider vorher festgelegten grant type.
3. Der Client authentisiert sich beim OAuth Service Provider und fragt nach einem Access Token mittels dem vom Resource Owner erhaltenen Authorization Grant.
4. Der Authorization Server authentisiert den Client und validiert den Authorization Grant, vergibt aufgrund des Resultats den Access Token.
5. Der Client fragt die geschützte Ressource vom Resource Server an, dabei authentifiziert er sich mit dem erhaltenen Access Token.
6. Der Resource Server validiert das Access Token und beantwortet anschliessen den Request.

Authorization Code Flow

grant_type="authorization_code"

Hierbei befindet sich ein Authorization Server zwischen Client und Resource Owner. Statt einer direkten Anfrage vom Client zum Resource Owner, wird der Resource Owner via Browser (User-Agent) zu einem Authorization Server geleitet. Dort authentifiziert sich der Resource Owner gegenüber dem Authorization Server und vergibt die Berechtigung für den Client. Danach wird der Resource Owner mit einem Authorization Code zurück zum Client weitergeleitet. Anschliessend kann der Client mit dem Authorization Code den Access Token abholen. Beim Access Token Request muss sich der Client noch authentifizieren, wenn es sich um einen confidential Client handelt oder er über Client Zugangsdaten verfügt.

Die Ausgabe eines Refresh Tokens zusammen mit dem Access Token ist optional.

Der ausgestellte Authorization Code sollte maximal 10 Minuten gültig sein. Er sollte kurz nach Verwendung annulliert werden, um das Risiko eines Authorization Code-Leaks zu verhindern. Der Authorization Code darf nicht mehr als einmal verwendet werden, passiert dies sollte der Request verworfen werden und sämtliche ausgestellten Tokens basierend auf diesem Authorization Code annulliert werden.

Im Fehlerfall sollte der Resource Owner durch den Authorization Server über die Umstände informiert werden.

Der Security Mehrwert kommt davon, dass der Access Token direkt vom Authorization Server an den Client gesendet wird und nicht über den Browser des Resource Owners geht und somit offengelegt wird gegenüber ihm und möglichen weiteren Drittparteien.

Implicit Flow

response_type="token"

Bei Schritt 6 handelt es sich um die Ausführung des erhaltenen Scripts aus Schritt 5, um den Access Token aus dem URI Fragment herauszulesen.

Dieser Prozess ist eine vereinfachte Version des Authorization Code Flows und ist für public Clienttypen ausgelegt. In diesem Ablauf wird dem Client direkt ein Access Token ausgestellt und ein Authorization Code fällt somit weg.

Die Authentifizierung des Clients durch den Authorization Server fällt weg, da public Clienttypen die sichere Aufbewahrung von eigenen Client Zugangsdaten nicht umsetzen können.

Bei dieser Übergabe wird der Access Token gegenüber dem Resource Owner und anderen Applikationen, welche Zugriff auf den Browser des Resource Owners haben, einsehbar.

Der Implicit Flow beschleunigt den OAuth Prozess durch das Weglassen der Entgegennahme des Authorization Codes und dessen Umtausch zum Erhalt des Access Tokens. Dadurch wird der Access Token jedoch anderen Parteien zugänglich und büsst an Sicherheit ein.

Der Implicit Flow unterstützt keine Refresh Tokens.

Resource Owner Password Credentials Flow

grant_type="password"

Hierbei wird direkt der Benutzername und das Passwort des Resource Owners als Authorization Grant verwendet, um ein Access Token zu erhalten.

Dieser Ablauf sollte nur eingesetzt werden, wenn der Client aktuell keinen anderen OAuth Flow unterstützt und zwingend OAuth eingesetzt werden muss. Der Einsatz wird dieses Flows wird gemäss Internet-Draft nicht empfohlen, da dabei die Zugangsdaten des Resource Owners gegenüber dem Client geleakt werden, vielen Dank an @alcastronic für diesen Hinweis.

Wenn ein langlebiges Access oder Refresh Token dem Client ausgegeben wird, kann für diese Zeitspanne auf die erneute Übermittlung der Zugangsdaten verzichtet werden. Dadurch gibt der Resource Owner einmalig seine Zugangsdaten ein und der Client speichert das erhaltene Token. Dies macht in vereinzelten Anwendungsbereichen Sinn. Dadurch können auch existierende direkte Authentifizierungsverfahren wie HTTP Basic Authentication abgelöst werden.

Nach der Ausstellung des Access Tokens muss der Client die erhaltenen Zugangsdaten des Resource Owners aus dessen Speicher entfernen.

Da der Access Token Request hier primär aus Benutzername und Passwort besteht, beziehungsweise dies den Authorization Grant ausmacht, muss der dazugehörige Endpoint des Authorization Servers gegen Brute-Force-Angriffe geschützt sein.

Client Credentials Flow

grant_type="client_credentials"

Dieser Ablauf wird eingesetzt, wenn der Client der Resource Owner selbst ist oder der Client bereits zuvor für die angefragte Ressource autorisiert wurde. Gerade Machine-To-Machine (M2M) Applikationen verwenden diesen Flow häufig, wie zum Beispiel Daemons oder Services im Backend. Dabei verwendet der Client nur seine Zugangsdaten oder andere Formen von Client Authentifizierung gegenüber dem Authorization Server. Dieser Flow sollte nur mit vertrauenswürdigen Clients eingesetzt werden.

Access Token erneuern mittels Refresh Token

Die Ausgabe von Refresh Tokens ist optional, ist jedoch je nach Applikation und verwendetem Flow sinnvoll. Wenn die Gültigkeit des Access Tokens verstrichen ist, kann der Client falls er im Besitz eines Refresh Tokens ist, sich damit ein neues Access Token beim Authorization Server ausstellen lassen. Der Refresh Token ist typischerweise langlebig und an den Client gebunden, welcher den initialen Access Token Request gestellt hat. Wenn es sich um einen confidential Client handelt oder er sich beim initialen Request mit Client Zugangsdaten authentisiert hat, muss er diese erneut mitliefern. Der Authorization Server muss neben den Client Zugangsdaten, falls notwendig auch prüfen, ob der Client mit dem für ihn bestimmten Refresh Token daherkommt.

Falls alle gelieferten Zugangsdaten und der Refresh Token valide sind, wird ein neues Access Token und optional noch ein neuer Refresh Token ausgestellt. Bei einer Neuausstellung des Refresh Tokens muss der Client den Alten durch den neuen Refresh Token ersetzen. Der Authorization Server hingegen kann den alten Refresh Token annullieren, muss aber nicht. Der Scope des neuen Refresh Tokens entspricht dem Scope des alten Refresh Tokens.

Fazit

Bei der Implementierung einer neuen OAuth Lösung ist es wichtig anhand des spezifizierten Clients, geltenden Sicherheitsanforderungen sowie getätigten Sicherheitsüberlegungen den geeigneten Flow auszuwählen. Bei einer klassischen Webapplikation mit Backend auf einem Webserver, welcher Client Zugangsdaten sicher aufbewahren und vor Fremdzugriff schützten kann, ist der Authorization Code Flow die geeignete Wahl. Ob dabei optionale Refresh Tokens ausgestellt werden, muss je nach Anwendungsszenario analysiert werden.

Zurzeit ist OAuth 2.1 in Arbeit, welches die zum OAuth 2.0 core RFC 6749 zusätzlich publizierten RFCs vereinen soll.

Über den Autor

Ralph Meier hat eine Lehre als Applikationsentwickler, Fokus Webentwicklung mit Java, bei einer Schweizer Grossbank absolviert und danach einen Bachelor of Science ZFH in Informatik an der ZHAW School of Engineering abgeschlossen. Er fokussiert sich auf die sicherheitstechnische Untersuchung von Webapplikationen. (ORCID 0000-0002-3997-8482)

Links

• https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.4
• https://datatracker.ietf.org/doc/html/rfc6749
• https://oauth.net/2.1/