Was ist der Zweck des impliziten Berechtigungsberechtigungstyps in OAuth 2?

Ich weiß nicht, ob ich nur einen blinden Fleck habe oder was, aber ich habe die OAuth 2-Spezifikation viele Male gelesen und die Mailinglisten-Archive durchgesehen, und ich habe noch keine gute Erklärung dafür gefunden, warum der implizite Zuschuss Der Fluss zum Erhalten von Zugriffstoken wurde entwickelt. Im Vergleich zum Authorization Code Grant scheint die Clientauthentifizierung ohne zwingenden Grund einfach aufzugeben. Wie wird dies "für Clients optimiert, die in einem Browser mithilfe einer Skriptsprache implementiert sind" (um die Spezifikation zu zitieren)?

Beide Flows beginnen gleich (Quelle: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

1. Der Client initiiert den Ablauf, indem er den Benutzeragenten des Ressourcenbesitzers an den Autorisierungsendpunkt weiterleitet.
2. Der Autorisierungsserver authentifiziert den Ressourcenbesitzer (über den Benutzeragenten) und stellt fest, ob der Ressourcenbesitzer die Zugriffsanforderung des Clients gewährt oder verweigert.
3. Angenommen, der Ressourcenbesitzer gewährt Zugriff, leitet der Autorisierungsserver den Benutzeragenten mithilfe des zuvor angegebenen Umleitungs-URI (in der Anforderung oder während der Clientregistrierung) zurück zum Client.
   • Der Umleitungs-URI enthält einen Autorisierungscode (Autorisierungscode-Fluss).
   • Der Umleitungs-URI enthält das Zugriffstoken im URI-Fragment (impliziter Fluss).

Hier teilen sich die Flüsse. In beiden Fällen befindet sich der Umleitungs-URI zu diesem Zeitpunkt auf einem vom Client gehosteten Endpunkt:

• Wenn der Benutzeragent im Autorisierungscodefluss diesen Endpunkt mit dem Autorisierungscode im URI trifft, tauscht der Code an diesem Endpunkt den Autorisierungscode zusammen mit seinen Client-Anmeldeinformationen gegen ein Zugriffstoken aus, das er dann nach Bedarf verwenden kann. Es könnte beispielsweise in eine Webseite geschrieben werden, auf die ein Skript auf der Seite zugreifen kann.
• Der implizite Ablauf überspringt diesen Clientauthentifizierungsschritt vollständig und lädt lediglich eine Webseite mit Client-Skript. Es gibt hier einen niedlichen Trick mit dem URL-Fragment, das verhindert, dass das Zugriffstoken zu viel herumgereicht wird, aber das Endergebnis ist im Wesentlichen dasselbe: Die vom Client gehostete Site stellt eine Seite mit einem Skript bereit, das das Zugriffstoken abrufen kann .
  

Daher meine Frage: Was wurde hier durch Überspringen des Clientauthentifizierungsschritts erreicht?

Hier sind meine Gedanken:

Der Zweck von Auth-Code + Token im Autorisierungscode-Fluss besteht darin, dass Token und Client-Geheimnis niemals dem Ressourcenbesitzer zugänglich gemacht werden, da sie von Server zu Server reisen.

Auf der anderen Seite gilt der implizite Grant Flow für Clients, die vollständig mit Javascript implementiert sind und im Browser des Ressourcenbesitzers ausgeführt werden. Sie benötigen keinen serverseitigen Code, um diesen Flow zu verwenden. Wenn dann alles im Browser des Ressourcenbesitzers passiert, macht es keinen Sinn mehr, Authentifizierungscode und Client-Geheimnis auszugeben, da Token und Client-Geheimnis weiterhin mit dem Ressourcenbesitzer geteilt werden. Das Einbeziehen von Authentifizierungscode und Client-Geheimnis macht den Ablauf nur komplexer, ohne dass mehr echte Sicherheit hinzugefügt wird.

Also die Antwort auf "Was wurde gewonnen?" ist "Einfachheit".

Es ist aus Sicherheitsgründen da, nicht der Einfachheit halber.

Sie sollten den Unterschied zwischen dem Benutzeragenten und dem Client berücksichtigen :

Der Benutzeragent ist die Software, mit der der Benutzer ("Ressourcenbesitzer") mit anderen Teilen des Systems (Authentifizierungsserver und Ressourcenserver) kommuniziert.

Der Client ist die Software, die auf die Ressourcen des Benutzers auf dem Ressourcenserver zugreifen möchte.

Bei entkoppeltem User-Agent und Client ist der Authorization Code Grant sinnvoll. Beispielsweise verwendet der Benutzer einen Webbrowser (User-Agent), um sich mit seinem Facebook-Konto bei Kickstarter anzumelden. In diesem Fall ist der Client einer der Kickstarter-Server, der die Benutzeranmeldungen verwaltet. Dieser Server erhält das Zugriffstoken und das Aktualisierungstoken von Facebook. Daher kann dieser Client-Typ aufgrund des eingeschränkten Zugriffs als "sicher" eingestuft werden. Die Token können gespeichert werden, und Kickstarter kann ohne Benutzerinteraktion auf die Ressourcen der Benutzer zugreifen und sogar die Zugriffstoken aktualisieren.

Wenn der Benutzeragent und der Client gekoppelt sind (z. B. native mobile Anwendung, Javascript-Anwendung), kann der implizite Autorisierungsworkflow angewendet werden. Es basiert auf der Anwesenheit des Ressourcenbesitzers (zur Eingabe der Anmeldeinformationen) und unterstützt keine Aktualisierungstoken. Wenn dieser Client das Zugriffstoken zur späteren Verwendung speichert, handelt es sich um ein Sicherheitsproblem, da das Token von anderen Anwendungen oder Benutzern des Clients problemlos extrahiert werden kann. Das Fehlen des Aktualisierungstokens ist ein zusätzlicher Hinweis darauf, dass diese Methode nicht für den Zugriff auf die Benutzerressourcen in Abwesenheit des Benutzers ausgelegt ist.

Die übliche Erklärung ist, dass die implizite Gewährung einfacher zu implementieren ist, wenn Sie einen JavaScript-Client verwenden. Aber ich denke, das ist die falsche Sichtweise. Wenn Sie einen JavaScript-Client verwenden, der geschützte Ressourcen direkt über XMLHttpRequest anfordert, ist die implizite Gewährung Ihre einzige Option, obwohl sie weniger sicher ist. *

Die Berechtigung zum Autorisierungscode bietet zusätzliche Sicherheit, funktioniert jedoch nur, wenn ein Webserver die geschützten Ressourcen anfordert. Da der Webserver das Zugriffstoken speichern kann, besteht ein geringeres Risiko, dass das Zugriffstoken dem Internet ausgesetzt wird, und Sie können ein Token ausstellen, das lange hält. Und da der Webserver vertrauenswürdig ist, kann ihm ein "Aktualisierungstoken" zugewiesen werden, sodass er nach Ablauf des alten ein neues Zugriffstoken erhalten kann.

Aber - und dies ist ein Punkt, der leicht zu übersehen ist - die Sicherheit des Autorisierungscodeflusses funktioniert nur, wenn der Webserver durch eine Sitzung geschützt ist, die mit Benutzerauthentifizierung (Login) eingerichtet wird. Ohne eine Sitzung könnte ein nicht vertrauenswürdiger Benutzer einfach mithilfe der client_id Anforderungen an den Webserver stellen, und es wäre dasselbe, als hätte der Benutzer das Zugriffstoken. Das Hinzufügen einer Sitzung bedeutet, dass nur ein authentifizierter Benutzer auf die geschützten Ressourcen zugreifen kann. Die client_id ist nur die "Identität" der JS-Webanwendung, nicht die Authentifizierung dieser Webanwendung.

Dies bedeutet auch, dass Sie die Sitzung beenden können, bevor das OAuth-Token abläuft. Es gibt keine Standardmethode, um ein Zugriffstoken ungültig zu machen. Wenn Ihre Sitzung jedoch abläuft, ist das Zugriffstoken nutzlos, da es nur der Webserver kennt. Wenn ein nicht vertrauenswürdiger Benutzer Zugriff auf Ihren Sitzungsschlüssel erhält, kann er nur so lange auf die geschützten Ressourcen zugreifen, wie die Sitzung gültig ist.

Wenn kein Webserver vorhanden ist, müssen Sie die implizite Berechtigung verwenden. Dies bedeutet jedoch, dass das Zugriffstoken dem Internet ausgesetzt ist. Wenn ein nicht vertrauenswürdiger Benutzer Zugriff darauf erhält, kann er es verwenden, bis es abläuft. Dies bedeutet, dass sie länger Zugriff darauf haben als mit einem Autorisierungscode. Daher sollten Sie in Betracht ziehen, das Token früher ablaufen zu lassen und den Zugriff auf vertraulichere Ressourcen zu vermeiden.

* BEARBEITEN: In jüngerer Zeit wird empfohlen, die implizite Berechtigung auch bei Webanwendungen ohne Server nicht zu verwenden. Stattdessen können Sie die mit einem leeren Geheimnis konfigurierte Berechtigung für den Autorisierungscode zusammen mit PKCE verwenden. Durch die Erteilung des Authentifizierungscodes wird vermieden, dass das Zugriffstoken in Ihrem Browserverlauf gespeichert wird, und durch PKCE wird vermieden, dass es angezeigt wird, wenn jemand die Umleitungs-URL missbraucht, um den Authentifizierungscode zu stehlen. In diesem Fall müsste der Server die Rückgabe eines Aktualisierungstokens vermeiden, da Ihr Client es wahrscheinlich nicht sicher speichern kann. Außerdem sollte ein Zugriffstoken mit denselben oben genannten Einschränkungen ausgestellt werden.

Es läuft darauf hinaus: Wenn ein Benutzer eine browserbasierte oder "öffentliche" (JavaScript) Webanwendung ohne serverseitige Komponente ausführt, vertraut der Benutzer implizit der App (und dem Browser, in dem sie ausgeführt wird, möglicherweise mit einem anderen Browser) -basierte Apps ...).

Es gibt keinen Remote-Server eines Drittanbieters, nur den Ressourcenserver. Ein Autorisierungscode hat keinen Vorteil, da es außer dem Browser, der im Namen des Benutzers handelt, keinen anderen Agenten gibt . Client-Anmeldeinformationen haben aus demselben Grund keinen Vorteil. ( Jeder Client kann versuchen, diesen Flow zu verwenden.)

Die Auswirkungen auf die Sicherheit sind jedoch erheblich. Von http://tools.ietf.org/html/rfc6749#section-10.3 :

Bei Verwendung des impliziten Grant-Typs wird das Zugriffstoken im URI-Fragment übertragen, wodurch es Unbefugten zugänglich gemacht werden kann.

Von http://tools.ietf.org/html/rfc6749#section-10.16 :

Ein Ressourcenbesitzer kann den Zugriff auf eine Ressource bereitwillig delegieren, indem er dem böswilligen Client eines Angreifers ein Zugriffstoken gewährt. Dies kann auf Phishing oder einen anderen Vorwand zurückzuführen sein ...

Ich bin mir nicht sicher, ob ich die Antwort und Dans Kommentar richtig verstehe. Es scheint mir, dass die Antwort einige Fakten korrekt angegeben hat, aber genau darauf hinweist, was OP gefragt hat. Wenn ich das richtig verstehe, besteht der Hauptvorteil des impliziten Grant-Flows darin, dass ein Client wie die JS-App (z. B. die Chrome-Erweiterung) das Client-Geheimnis nicht preisgeben muss.

Dan Taflin sagte:

... im Autorisierungscode-Fluss muss der Ressourcenbesitzer das Zugriffstoken nie sehen, während dies in Javascript-Clients unvermeidbar ist. Das Client-Geheimnis konnte jedoch mithilfe des Autorisierungscode-Flusses weiterhin vor Javascript-Clients geschützt werden.

Vielleicht habe ich Sie falsch verstanden, aber der Client (in diesem Fall die JS-App) muss den Client-Berechtigungsnachweis (Client-Schlüssel und Geheimnis) im Autorisierungscode-Fluss an den Ressourcenserver übergeben, oder? Das Client-Geheimnis kann nicht "von JS ferngehalten" werden.

Während Implicit Grant entwickelt wurde, um Apps zu unterstützen, die ein Clientgeheimnis nicht schützen konnten, einschließlich clientseitiger JavaScript-Apps, implementieren einige Anbieter stattdessen eine Alternative mit Autorisierungscode ohne Clientgeheimnis. Der OAuth 2.0 IETF RFC-6749 wurde 2012 veröffentlicht und aktuelle Empfehlungen, einige aktuelle Diskussionen, stammen aus dem Jahr 2017.

Die Diskussion 2017 über die IETF OAuth-Mailingliste ist bei folgenden Implementierern erhältlich:

• Redhat: https://www.ietf.org/.../oauth/current/msg16966.html
• Deutsche Telekom: https://www.ietf.org/.../oauth/current/msg16968.html
• Smart Health IT: https://www.ietf.org/.../oauth/current/msg16967.html

Lesen Sie hier mehr:

• https://aaronparecki.com/oauth-2-simplified/
• https://aaronparecki.com/oauth-2-simplified/#single-page-apps

Implizit wurde zuvor für Kunden ohne Geheimnis empfohlen, wurde jedoch durch die Verwendung des Autorisierungscode-Zuschusses ohne Geheimnis ersetzt.

...

Bisher wurde empfohlen, dass browserbasierte Apps den "impliziten" Flow verwenden, der sofort ein Zugriffstoken zurückgibt und keinen Token-Austauschschritt hat. In der Zeit seit der ursprünglichen Erstellung der Spezifikation wurde die Best Practice der Branche geändert, um zu empfehlen, den Autorisierungscode-Fluss ohne das Client-Geheimnis zu verwenden. Dies bietet mehr Möglichkeiten zum Erstellen eines sicheren Flusses, z. B. mithilfe des Statusparameters. Referenzen: Redhat , Deutsche Telekom , Smart Health IT .

Der Wechsel zu Auth Code ohne Client Secret von Implicit Grant wird hier auch für mobile Apps erwähnt:

• https://aaronparecki.com/oauth-2-simplified/#mobile-apps

Zusätzlich zu den anderen Antworten ist es wichtig zu wissen, dass das implizite Profil nur einen Front-Channel-Flow zulässt, im Gegensatz zum Authorization Code-Flow, für den ein Rückruf an den Authorization Server erforderlich ist. Dies wird in OpenID Connect deutlich, einem SSO-Protokoll, das auf Auth 2.0 aufbaut, wobei der implizite Ablauf der recht beliebten SAML-POST-Bindung und der Autorisierungscode-Fluss der weniger weit verbreiteten SAML-Artefaktbindung ähnelt

Wenn im impliziten Ablauf der Browser des Benutzers beschädigt ist (böse Erweiterung / Virus), erhält die Beschädigung Zugriff auf die Ressourcen des Benutzers und kann die schlechten Dinge tun.

Im Auth-Flow kann die Beschädigung nicht, da das Client-Geheimnis nicht bekannt ist.

https://tools.ietf.org/html/rfc6749#page-8

Implizit

Die implizite Gewährung ist ein vereinfachter Autorisierungscode-Fluss, der für Clients optimiert ist, die in einem Browser mithilfe einer Skriptsprache wie JavaScript implementiert sind. Im impliziten Ablauf wird dem Client anstelle eines Berechtigungscodes direkt ein Zugriffstoken ausgestellt (als Ergebnis der Autorisierung des Ressourcenbesitzers). Der Grant-Typ ist implizit, da keine Zwischenanmeldeinformationen (z. B. ein Autorisierungscode) ausgegeben werden (und später zum Abrufen eines Zugriffstokens verwendet werden).

Wenn während des impliziten Grant-Flows ein Zugriffstoken ausgegeben wird,
authentifiziert der Autorisierungsserver den Client nicht. In einigen
Fällen kann die Clientidentität über den Umleitungs-URI überprüft werden, der
zum Übermitteln des Zugriffstokens an den Client verwendet wird. Das Zugriffstoken kann für den Ressourcenbesitzer oder andere Anwendungen mit Zugriff auf den Benutzeragenten des Ressourcenbesitzers verfügbar gemacht werden.

Implizite Zuschüsse verbessern die Reaktionsfähigkeit und Effizienz einiger
Clients (z. B. eines Clients, der als In-Browser-Anwendung implementiert ist),
da dadurch weniger Roundtrips erforderlich sind, um ein
Zugriffstoken zu erhalten .

Ich denke, Will Cain hat darauf geantwortet, als er sagte: "Client-Anmeldeinformationen haben aus demselben Grund keinen Vorteil. (Jeder Client kann versuchen, diesen Flow zu verwenden.)" Bedenken Sie auch, dass redirect_uri für impliziten Flow möglicherweise "localhost" ist - kein Rückruf wird vom Autorisierungsserver für den impliziten Ablauf erstellt. Da es keine Möglichkeit gibt, dem Kunden vorab zu vertrauen, müsste der Benutzer die Freigabe von Benutzeransprüchen genehmigen.

Der implizite Zuschuss ermöglicht das Abrufen von Token vom Autorisierungsendpunkt mit a GET. Dies bedeutet, dass der Autorisierungsserver CORS nicht unterstützen muss.

Wenn dies kein Problem darstellt und keine anderen Probleme im Zusammenhang mit dem Autorisierungsserver unflexibel sind (z. B. Aktualisierungstoken sind aus irgendeinem Grund nicht optional), ist der Autorisierungscodefluss selbst für öffentliche Kunden gemäß den jüngsten Branchentrends der bevorzugte und zumindest zu dieser (aktuellen) Instanz eines offiziellen Entwurfs .

In der Vergangenheit gab es andere Gründe, den impliziten Ablauf zu implementieren, aber es scheint, dass sie derzeit durch Sicherheitsvorteile aufgewogen werden, die die Erteilung des Autorisierungscodes bietet, darunter:

• Option zur Bereitstellung und Verwendung der Token über einen Rückkanal für vertrauliche Kunden
• Token im Browserverlauf für öffentliche Clients nicht verfügbar machen
• Unterbrechen eines nicht autorisierten Datenflusses vor der Ausgabe von Token - mit PKCE für "alle Arten von OAuth-Clients"

Ich habe gerade einen Artikel über OAuth 2.0 gesehen. Der Autor gibt an, dass der Grund für den impliziten Ablauf darin besteht, dass JS-Apps in ihren Anforderungen sehr eingeschränkt waren:

Wenn Sie sich fragen, warum der implizite Typ in OAuth 2.0 enthalten war, ist die Erklärung einfach: Same Origin Policy. Damals durften Frontend-Anwendungen keine Anforderungen an verschiedene Hosts senden, um das Zugriffstoken mithilfe von Code zu erhalten. Heute haben wir CORS (Cross-Origin Resource Sharing).

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611