it-swarm.com.de

Warum gibt es in OAuth2 einen "Authorization Code" -Fluss, wenn der "Implizite" -Fluss so gut funktioniert?

Mit dem "Impliziten" -Fluss erhält der Client (wahrscheinlich ein Browser) ein Zugriffstoken, nachdem der Ressourcenbesitzer (d. H. Der Benutzer) den Zugriff erteilt hat.

Mit dem "Autorisierungscode" -Fluss erhält der Client (normalerweise ein Webserver) jedoch nur einen Autorisierungscode, nachdem der Ressourcenbesitzer (d. H. Der Benutzer) den Zugriff erteilt hat. Mit diesem Berechtigungscode ruft der Client die API erneut auf und übergibt client_id und client_secret zusammen mit dem Berechtigungscode, um das Zugriffstoken abzurufen. Alles hier gut beschrieben .

Beide Flows führen zu genau demselben Ergebnis: einem Zugriffstoken. Der "implizite" Ablauf ist jedoch viel einfacher.

Die Frage: Warum mit "Authorization Code" fließen, wenn "implizite" Fließnähte in Ordnung sein sollen? Warum nicht auch "Implicit" für Webserver verwenden?

Es ist mehr Arbeit sowohl für den Anbieter als auch für den Kunden.

225
Aron Woost

tl; dr: Dies ist alles aus Sicherheitsgründen.

OAuth 2.0 wollte diese beiden Kriterien erfüllen:

  1. Sie möchten Entwicklern die Verwendung von Nicht-HTTPS-Umleitungs-URI erlauben, da nicht alle Entwickler über einen SSL-fähigen Server verfügen und dieser nicht immer ordnungsgemäß konfiguriert ist (nicht selbstsignierte, vertrauenswürdige SSL-Zertifikate, synchronisierte Serveruhr ...).
  2. Sie möchten nicht, dass Hacker Zugriffs-/Aktualisierungstoken stehlen können, indem sie Anforderungen abfangen.

Details unten:

Der implizite Ablauf ist aus Sicherheitsgründen nur in einer Browserumgebung möglich:

Im impliziten Fluss wird das Zugriffstoken direkt als Hash-Fragment übergeben (nicht als URL-Parameter). Eine wichtige Sache bei Hash-Fragmenten ist, dass, sobald Sie einem Link folgen, der ein Hash-Fragment enthält, nur der Browser das Hash-Fragment kennt. Browser übergeben das Hash-Fragment direkt an die Ziel-Webseite (die Umleitungs-URI/die Webseite des Clients). Hash-Fragmente haben folgende Eigenschaften:

  • Sie sind nicht Teil der HTTP-Anforderung und können daher nicht von Servern gelesen und daher nicht von zwischengeschalteten Servern/Routern abgefangen werden (dies ist wichtig).
  • Sie existieren nur im Browser - auf der Clientseite -, sodass das Hash-Fragment nur mit JavaScript gelesen werden kann, das auf der Seite ausgeführt wird.

Auf diese Weise kann ein Zugriffstoken direkt an den Client übergeben werden, ohne dass die Gefahr besteht, dass er von einem zwischengeschalteten Server abgefangen wird. Dies hat den Vorbehalt, nur clientseitig möglich zu sein, und erfordert, dass JavaScript clientseitig ausgeführt wird, um das Zugriffstoken zu verwenden.

Im Autorisierungscode-Fluss ist es nicht möglich, ein Zugriffstoken direkt in einem URL-Parameter zu übergeben, da URL-Parameter Teil der HTTP-Anforderung sind Hunderte sein) könnte in der Lage sein, das Zugriffstoken zu lesen, wenn Sie keine verschlüsselte Verbindung (HTTPS) verwenden, die sogenannte Man-in-the-Middle-Angriffe ermöglicht.

Das direkte Übergeben des Zugriffstokens in einen URL-Parameter könnte theoretisch möglich sein, aber der Authentifizierungsserver muss sicherstellen, dass der Umleitungs-URI HTTPS mit TLS-Verschlüsselung und einem "vertrauenswürdigen" SSL-Zertifikat verwendet (normalerweise von einer nicht kostenlosen Zertifizierungsstelle). um sicherzustellen, dass der Zielserver legitim ist und die HTTP-Anforderung vollständig verschlüsselt ist. Wenn alle Entwickler ein SSL-Zertifikat erwerben und SSL in ihrer Domain ordnungsgemäß konfigurieren, würde dies große Schmerzen verursachen und die Akzeptanz erheblich verlangsamen. Aus diesem Grund wird ein zwischengeschalteter, einmal verwendbarer "Autorisierungscode" bereitgestellt, der nur dem legitimen Empfänger den Austausch ermöglicht (da Sie das Client-Geheimnis benötigen) und potenziellen Hackern, die die Anforderungen über unverschlüsselte Transaktionen abfangen, keinen Nutzen bringt (weil sie das Kundengeheimnis nicht kennen).

Sie könnten auch argumentieren, dass der implizite Datenfluss weniger sicher ist. Es gibt potenzielle Angriffsmethoden wie das Spoofing der Domain beim Redirect, beispielsweise durch das Hijacken der IP-Adresse der Client-Website. Dies ist einer der Gründe, warum der implizite Fluss nur Zugriffstoken gewährt (die nur eine begrenzte Zeit verwenden sollen) und Token niemals aktualisiert (die zeitlich unbegrenzt sind). Um dieses Problem zu beheben, empfehle ich Ihnen, Ihre Webseiten nach Möglichkeit auf einem HTTPS-fähigen Server zu hosten.

253
Nicolas Garnier

Der implizite Fluss macht den gesamten Fluss ziemlich einfach, aber auch weniger sicher .
Da die Clientanwendung, bei der es sich normalerweise um JavaScript handelt, das in einem Browser ausgeführt wird, weniger vertrauenswürdig ist, werden keine Aktualisierungstoken für den dauerhaften Zugriff zurückgegeben.
Sie sollten diesen Flow für Anwendungen verwenden, die vorübergehend (einige Stunden) auf die Daten des Benutzers zugreifen müssen.
Das Zurückgeben eines Zugriffstokens an JavaScript-Clients bedeutet auch, dass Ihre browserbasierte Anwendung besondere Sorgfalt erfordert - denken Sie an XSS-Angriffe, durch die das Zugriffstoken an andere Systeme verloren gehen kann.

https://labs.hybris.com/2012/06/05/oauth2-the-implicit-flow-aka-as-the-client-side-flow

8
lakesare

Aus der OAuth-Spezifikation :

4.2. Implizite Bewilligung

Der implizite Grant-Typ wird zum Abrufen von Zugriffstoken verwendet (er unterstützt nicht die Ausgabe von Aktualisierungstoken) und ist für öffentliche Clients optimiert, von denen bekannt ist, dass sie einen bestimmten Umleitungs-URI verwenden. Diese Clients werden normalerweise in einem Browser mit einer Skriptsprache wie JavaScript implementiert.

Da es sich um einen umleitungsbasierten Fluss handelt, muss der Client in der Lage sein, mit dem Benutzeragenten des Ressourcenbesitzers (normalerweise einem Webbrowser) zu interagieren und eingehende Anforderungen (über eine Umleitung) vom Autorisierungsserver zu empfangen.

Im Gegensatz zum Berechtigungscode-Erteilungstyp, bei dem der Client separate Anforderungen für die Autorisierung und für ein Zugriffstoken stellt, erhält der Client das Zugriffstoken als Ergebnis der Autorisierungsanforderung.

Der implizite Grant-Typ enthält keine Clientauthentifizierung und basiert auf dem Vorhandensein des Ressourcenbesitzers und der Registrierung des Umleitungs-URI. Da das Zugriffstoken in den Umleitungs-URI codiert ist, ist es möglicherweise für den Ressourcenbesitzer und andere Anwendungen verfügbar, die sich auf demselben Gerät befinden.

Also, was können wir berücksichtigen:

  1. Dies ist für public OAuth d. H., Wenn der Client nicht registriert werden muss und keine eigenen Clientgeheimnisse hat. Der Authentifizierungsserver überprüft jedoch die Weiterleitungs-URL und dies ist für die Sicherheit ausreichend.

  2. Das Zugriffstoken wird in der Adressleiste des Browsers angezeigt, sodass der Benutzer die URL kopieren und an eine andere Person senden kann. Außerdem wird es als Benutzer protokolliert, d. H. Es handelt sich um eine Art Sitzungsfixierung. Der Browser führt jedoch eine zusätzliche Umleitung durch, indem er den Verlauf ersetzt, um das Hash-Fragment aus der URL zu entfernen. Es ist auch möglich, dass ein Hacker das Zugriffstoken stiehlt, indem er einen HTTP-Verkehr abfängt. Dies kann jedoch leicht durch HTTPS geschützt werden. Einige böswillige Browser-Erweiterungen können über die Adressleiste auf URLs zugreifen. Dies ist jedoch eine schlimme Situation, wie z. B. ein defektes HTTPS-Zertifikat. Und selbst der Auth-Code-Fluss kann hier nicht weiterhelfen. Was ich also sehen kann, ist, dass die Weitergabe des Zugriffstokens über ein Hash-Fragment der URL absolut sicher ist.

  3. Die Trennung von ephemerem Zugriffstoken und Aktualisierungstoken ist bei Verwendung von HTTPS nutzlos und, um ehrlich zu sein, selbst bei unformatiertem HTTP nicht so nützlich. Aber die Tatsache, dass der Client über den impliziten Datenfluss das Aktualisierungstoken nicht empfangen kann, ist ebenfalls Unsinn.

Daher denke ich, wir sollten einen neuen Grant Flow einführen, der „sicher implizit“ ist, der ausschließlich über https funktioniert, einen Aktualisierungstoken zulässt (oder den wir überhaupt loswerden sollten) und dem Grant Flow von Auth Cose vorzuziehen ist

2
stokito

Meine Antwort lautet: Sie können Implicit Flow mit dem Web-App-Server nicht sicher und einfach implementieren.

Der Autorisierungsprozess für die Web-App umfasst eine Benutzerinteraktion. Authentication Server sollte daher nach der Benutzerauthentifizierung und Zustimmung mleiten den Browser des Benutzers zurück zur Zielseite der Web-App (ich sehe keine andere Möglichkeit, den Benutzer zurück an zu übergeben) Web-App nach einiger Interaktion mit dem Authentication Server).

Das Token sollte also über eine Weiterleitungs-URL an die Web-App übergeben werden, oder?

Wie @NicolasGarnier in seiner Antwort und seinen Kommentaren erklärte, gibt es keine Möglichkeit, Token als URL-Fragment zu übergeben - es wird den Web-App-Server nicht erreichen.

Und das Übergeben eines Tokens als URL-Parameter der Weiterleitungs-URL wäre selbst unter HTTPS nicht sicher: Wenn die Zielseite ("Begrüßungsseite") Ressourcen (Bilder, Skripte usw.) enthält, werden diese Ressourcen vom Browser über die Serie abgerufen von HTTP (S) -Anfragen (von denen jede den HTTP-Header Referer enthält, der die genaue URL der "Begrüßungsseite" einschließlich der URL-Parameter enthält). Auf diese Weise kann der Token auslaufen.

Es scheint also keine Möglichkeit zu geben, ein Token in einer Weiterleitungs-URL weiterzuleiten. Aus diesem Grund benötigen Sie einen zweiten Aufruf (entweder vom Authentifizierungsserver zum Client (aber zu welcher URL?) Oder vom Client zum Authentifizierungsserver (der zweite Aufruf im Fluss des Autorisierungscodes)).

0
Lu55