OAuth 2.0 Flows - Merkmale und ihr Einsatzgebiet

OAuth 2.0 Flows

Merkmale und ihr Einsatzgebiet

Ralph Meier
von Ralph Meier
am 15. September 2022
Lesezeit: 13 Minuten

Keypoints

Finden Sie den geeigneten OAuth Flow für verschiedene Applikationsarten

  • OAuth ermöglicht autorisierter Zugriff auf Ressourcen ohne eigene Benutzerauthentifizierung
  • Auf Applikationsarten zugeschnittene OAuth Abläufe mit verschiedenen Eigenschaften
  • Ablauf, um abgelaufene Access Tokens mittels Refresh Tokens zu erneuern
  • Welche Flows sollten nur bei Clients mit grossem Vertrauen eingesetzt werden

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:

Akteur Beschreibung
Client / Client Application Eine Webapplikation oder andere Applikation, welche Zugriff auf geschützte Ressourcen mit Hilfe und im Namen des Resource Owners will.
Resource Owner Der Benutzer, welcher Zugriff auf die geschützte Ressource freigibt. Handelt es sich beim Resource Owner um einen Benutzer, wird dieser auch als End-User bezeichnet.
Resource Server Server, welcher die geschützten Ressourcen verwaltet.
Authorization Server Server, welcher den Resource Owner authentisiert und mit dessen Zustimmung Access Tokens für den Zugriff auf die gewünschte Ressource ausstellt.

Fachbegriffe

Begriff Beschreibung
Authorization Grant Widerspiegelt die Zugangsdaten des Resource Owners, quasi ein Berechtigungsnachweis. Dieser wird verwendet, um beim Authorization Server den Access Token einzufordern.
Access Token Zugangstoken, um auf geschützte Ressourcen zuzugreifen. Sie repräsentieren eine Autorisierung für den jeweiligen Client. Die darin enthaltenen Informationen sind unteranderem genauer Scope und festgelegte Zugriffzeitdauer.
Refresh Token Diese werden optional mit einem Access Token ausgestellt. Mit einem Refresh Token kann nach Ablauf der Gültigkeit des Access Tokens, ein neues Access Token beim Authorization Server abgeholt werden.

Unterschiedliche Clienttypen

OAuth Flows

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

Abstrakter OAuth Ablauf

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"

OAuth Authorization Code Flow

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"

OAuth Implicit Flow

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"

OAuth Resource Owner Password Credentials Flow

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"

OAuth Client Credentials Flow

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

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

Werden auch Ihre Daten im Darknet gehandelt?

Wir führen gerne für Sie ein Monitoring des Digitalen Untergrunds durch!

×
Web Cache Poisoning

Web Cache Poisoning

Ralph Meier

Sicherheit im Heimnetzwerk erhöhen

Sicherheit im Heimnetzwerk erhöhen

Ralph Meier

Reverse Engineering

Reverse Engineering

Ralph Meier

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv