it-swarm.com.de

Was ist der Zweck der Berechtigungsart für implizite Erteilung in OAuth 2?

Ich weiß nicht, ob ich nur eine Art blinder Fleck habe oder was, aber ich habe die Spezifikation von OAuth 2 oft gelesen und die Mailinglisten-Archive durchgelesen, und ich muss noch eine gute Erklärung dafür finden, warum der implizite Zuschuss erfolgt Es wurde ein Fluss zum Erhalten von Zugangstoken entwickelt. Verglichen mit dem Authorization Code Grant scheint die Clientauthentifizierung ohne zwingenden Grund aufzugeben. Wie wird dies "optimiert für Clients, die in einem Browser mit einer Skriptsprache implementiert sind" (um die Spezifikation anzugeben)?

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

  1. Der Client initiiert den Fluss, indem er den Benutzeragenten des Ressourcenbesitzers an den Autorisierungsendpunkt weiterleitet.
  2. Der Autorisierungsserver authentifiziert den Ressourceninhaber (über den Benutzeragenten) und legt fest, ob der Ressourceninhaber die Zugriffsanforderung des Clients erteilt oder verweigert.
  3. Unter der Annahme, dass der Ressourcenbesitzer Zugriff gewährt, leitet der Autorisierungsserver den Benutzeragenten mithilfe der zuvor angegebenen Umleitungs-URI (in der Anforderung oder während der Clientregistrierung) zurück an den 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 handelt es sich bei dem Umleitungs-URI zu diesem Zeitpunkt um einen vom Client gehosteten Endpunkt:

  • Wenn der Benutzeragent im Berechtigungscode den Endpunkt mit dem Berechtigungscode im URI trifft, tauscht der Code an diesem Endpunkt den Berechtigungscode zusammen mit seinen Clientanmeldeinformationen gegen ein Zugriffstoken aus, das er bei Bedarf verwenden kann. Es könnte beispielsweise in eine Webseite geschrieben werden, auf die ein Skript auf der Seite zugreifen kann.
  • Der implizite Fluss überspringt diesen Clientauthentifizierungsschritt vollständig und lädt einfach eine Webseite mit Clientskript. Hier gibt es einen Trick mit dem URL-Fragment, das verhindert, dass das Zugriffstoken zu viel weitergegeben wird, aber das Endergebnis ist im Wesentlichen dasselbe: Die vom Client gehostete Website stellt eine Seite mit einem Skript bereit, das das Zugriffstoken abrufen kann .

Daher meine Frage: Was wurde hier durch das Überspringen des Clientauthentifizierungsschrittes gewonnen?

226
Dan Taflin

Hier sind meine Gedanken:

Der Zweck von Auth-Code + Token im Berechtigungscodefluss besteht darin, dass Token und Client-Secret niemals für den Ressourcenbesitzer verfügbar gemacht werden, da sie von Server zu Server reisen.

Auf der anderen Seite ist der implizite Gewährungsfluss 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 Fluss zu verwenden. Wenn dann im Browser des Ressourcenbesitzers alles geschieht, ist es nicht mehr sinnvoll, Authentifizierungscode und Clientgeheimnis auszugeben, da das Token und das Clientgeheimnis weiterhin mit dem Ressourceninhaber gemeinsam genutzt werden. Durch das Einfügen von Auth-Code und Client-Secret wird der Ablauf komplexer, ohne die Sicherheit zu erhöhen.

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

177
Philip Peshin

Es ist aus Sicherheitsgründen da, nicht zur Vereinfachung.

Sie sollten den Unterschied zwischen dem user agent und dem client berücksichtigen:

Der Benutzeragent ist die Software, bei der der Benutzer ("Ressourceneigentümer") 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 entkoppelten User-Agent und Client ist der Authorization Code Grant sinnvoll. Z.B. Der Benutzer verwendet einen Webbrowser (User-Agent), um sich mit seinem Facebook-Konto bei Kickstarter anzumelden. In diesem Fall ist der Client einer der Server von Kickstarter, 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" betrachtet werden, die Token können gespeichert werden, und Kickstarter kann auf die Ressourcen der Benutzer zugreifen und sogar die Zugriffstoken ohne Benutzerinteraktion aktualisieren.

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

81
artkoenig

Die übliche Erklärung ist, dass die implizite Erteilung einfacher 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 Erteilung die einzige Option, jedoch weniger sicher.

Die Berechtigungscode-Erteilung bietet zusätzliche Sicherheit. Sie 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 ausgeben, das lange dauert. Da der Webserver vertrauenswürdig ist, kann ihm ein "Aktualisierungstoken" zugewiesen werden, sodass er ein neues Zugriffstoken erhält, wenn der alte Server abläuft.

Aber - und dies ist ein Punkt, den man leicht übersehen kann - die Sicherheit des Authorization-Code-Flusses funktioniert nur, wenn der Webserver mit einer Sitzung geschützt ist, die mit einer Benutzerauthentifizierung (Anmeldung) eingerichtet wird. Ohne Sitzung kann ein nicht vertrauenswürdiger Benutzer mithilfe der client_id einfach Anforderungen an den Webserver stellen. Dies ist derselbe, als wenn der Benutzer das Zugriffstoken hätte. 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-Webapp, nicht die Authentifizierung der Webapp.

Dies bedeutet auch, dass Sie die Sitzung beenden können, bevor das OAuth-Token abläuft. Es gibt keine Standardmethode, um ein Zugriffstoken für ungültig zu erklären. Wenn Ihre Sitzung jedoch abläuft, ist das Zugriffstoken unbrauchbar, da es nur der Webserver weiß. Wenn ein nicht vertrauenswürdiger Benutzer Zugriff auf Ihren Sitzungsschlüssel hat, kann er nur solange auf die geschützten Ressourcen zugreifen, wie die Sitzung gültig ist.

Wenn kein Webserver vorhanden ist, müssen Sie die implizite Erteilung verwenden. Dies bedeutet jedoch, dass das Zugriffstoken dem Internet ausgesetzt ist. Wenn ein nicht vertrauenswürdiger Benutzer Zugriff darauf erhält, kann er es bis zu seinem Ablauf verwenden. Dies bedeutet, dass sie länger als mit einem Berechtigungscode gewähren können. Daher sollten Sie in Erwägung ziehen, das Token früher auslaufen zu lassen, und den Zugriff auf empfindlichere Ressourcen vermeiden.

55
JW.

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

Es gibt keinen Fremdanbieter-Remoteserver, nur den Ressourcenserver. Ein Autorisierungscode hat keinen Vorteil, da außer dem Browser, der im Namen des Benutzers handelt, kein anderer Agent vorhanden ist. Kundenanmeldeinformationen können aus demselben Grund nicht verwendet werden. ( Jeder Client kann versuchen, diesen Flow zu verwenden.)

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

Bei Verwendung des impliziten Grant-Typs wird das Zugriffstoken im URI-Fragment übertragen, wodurch es für nicht autorisierte Parteien verfügbar gemacht werden kann.

From 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 erteilt. Dies kann an Phishing oder einem anderen Vorwand liegen ...

21
Will

Ich bin nicht sicher, ob ich die Antwort und Dans Kommentar richtig verstanden habe. Es scheint mir, dass die Antwort einige Tatsachen richtig erklärt hat, aber sie zeigt genau, was OP gefragt hat. Wenn ich es richtig verstanden habe, besteht der Hauptvorteil des impliziten Gewährungsflusses darin, dass ein Client wie die JS-App (z. B. die Chrome-Erweiterung) das Clientgeheimnis nicht preisgeben muss.

Dan Taflin sagte:

... im Berechtigungscode-Fluss muss der Ressourceneigentümer das Zugriffstoken nie sehen, während dies bei Javascript-Clients unvermeidlich ist. Das Client-Geheimnis könnte jedoch durch Verwendung des Autorisierungscode-Flusses vor Javascript-Clients zurückgehalten werden.

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

13
tzuchien.chiu

Während Implicit Grant zur Unterstützung von Apps entwickelt wurde, die ein Clientgeheimnis, einschließlich clientseitige JavaScript-Apps, nicht schützen konnten, implementieren einige Anbieter eine Alternative, die den Autorisierungscode ohne Clientgeheimnis verwendet. Die OAuth 2.0 IETF RFC-6749 wurde 2012 veröffentlicht. Aktuelle Empfehlungen sind einige Diskussionen aus dem Jahr 2017.

Eine Diskussion über die IETF OAuth-Mailingliste für 2017 ist bei diesen Implementierern verfügbar:

Lesen Sie hier mehr:

Implicit wurde zuvor für Clients ohne Geheimnis empfohlen, wurde jedoch durch Verwendung des Berechtigungscode-Zertifikats ohne Geheimnis ersetzt.

...

Bisher wurde empfohlen, dass browserbasierte Apps den Fluss "Implicit" verwenden, der ein Zugriffstoken sofort zurückgibt und keinen Tokenaustauschschritt enthält. In der Zeit, seit die Spezifikation ursprünglich geschrieben wurde, hat sich die bewährte Praxis der Branche geändert, um zu empfehlen, dass der Autorisierungscode-Fluss ohne das Clientgeheimnis verwendet wird. Dies bietet mehr Möglichkeiten zum Erstellen eines sicheren Flusses, z. B. die Verwendung des Zustandsparameters. Referenzen: Redhat , Deutsche Telekom , Smart Health IT .

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

6
Grokify

Wenn der Browser des Benutzers im impliziten Fluss beschädigt ist (bösartige Erweiterung/Virus), erhält die Beschädigung Zugriff auf die Ressourcen des Benutzers und kann das Schlechte tun.

Im Auth-Fluss kann die Beschädigung nicht erfolgen, da das Clientgeheimnis nicht bekannt ist.

3
Pace

zusätzlich zu den anderen Antworten ist es auch wichtig zu erkennen, dass das implizite Profil nur einen Front-Channel-Fluss zulässt, im Gegensatz zum Authorization-Code-Fluss, der einen Rückruf an den Authorization Server erfordert. Dies wird in OpenID Connect deutlich, einem SSO-Protokoll, das auf Auth 2.0 aufgebaut ist. Der implizite Fluss ähnelt der recht populären SAML POST - Bindung und der Authorization Code-Fluss ähnelt der weniger weit verbreiteten SAML Artifact-Bindung

3
Hans Z.

Ich glaube, Will Cain hat darauf geantwortet, als er sagte: "Es gibt keinen Vorteil für Client-Anmeldeinformationen aus demselben Grund. (Jeder Client kann versuchen, diesen Fluss zu verwenden.)" Denken Sie auch daran, dass redirect_uri für impliziten Fluss möglicherweise "localhost" ist - kein Rückruf wird vom Authorization Server für den impliziten Fluss erstellt. Da es nicht möglich ist, dem Kunden ein Vorvertrauen zu geben, muss der Benutzer die Freigabe von Benutzeransprüchen genehmigen.

1
Mike Schwartz

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

Implizit

Die implizite Erteilung ist ein vereinfachter Autorisierungscodefluss Optimiert für Clients, die mithilfe eines Skripts in einem Browser implementiert wurden Sprache wie JavaScript. Im impliziten Fluss anstelle von Wenn der Client einen Autorisierungscode ausgibt, erhält der Client eine Zugriffstoken direkt (als Ergebnis des Ressourceneigners Autorisierung). Der Gewährungstyp ist implizit, da kein Zwischenprodukt vorhanden ist Berechtigungsnachweise (z. B. ein Autorisierungscode) werden ausgegeben (und später verwendet, um ein Zugriffstoken zu erhalten).

Bei der Ausgabe eines Zugriffstokens während des impliziten Gewährungsablaufs wird der
Der Autorisierungsserver authentifiziert den Client nicht. In einigen
In diesem Fall kann die Client-Identität über den Umleitungs-URI überprüft werden
verwendet, um das Zugriffstoken an den Client zu übermitteln. Das Zugriffstoken kann dem Ressourceneigentümer oder anderen Anwendungen mit Zugriff auf .__ ausgesetzt sein. der Benutzeragent des Ressourcenbesitzers.

Implizite Zuschüsse verbessern die Reaktionsfähigkeit und Effizienz einiger
Clients (z. B. ein Client, der als Anwendung im Browser implementiert ist),
da es die Anzahl der benötigten Rundfahrten reduziert, um eine
Zugangstoken.

1
Rzv Razvan

Mit der impliziten Erteilung können Sie Token von Authorization Endpoint mit einer GET erhalten. Dies bedeutet, dass der Autorisierungsserver CORS nicht unterstützen muss. 

Wenn dies kein Problem ist und es keine anderen Probleme im Zusammenhang mit dem Berechtigungsserver gibt, die unflexibel waren (z. B. Aktualisierungs-Token sind aus irgendeinem Grund nicht optional), ist der Autorisierungscodefluß der bevorzugte, auch für öffentliche Clients, gemäß Recent Branchentrends und zumindest diese (aktuelle) Instanz eines offiziellen Entwurfs .

In der Vergangenheit gab es andere Gründe für die Implementierung des impliziten Flusses, aber es scheint, als würden sie derzeit durch die Sicherheitsvorteile, die der Autorisierungscode gewährt, aufgewogen, darunter:

  • option zur Bereitstellung und Verwendung der Token über einen Rückkanal für vertrauliche Clients 
  • keine Tokens im Browserverlauf für öffentliche Kunden verfügbar machen
  • unterbrechen eines nicht autorisierten Flusses, bevor Token ausgegeben werden - mit PKCE , für "alle Arten von OAuth-Clients"
0
ko la

Ich habe gerade einen Artikel über OAuth 2.0 gelesen. Der Autor gibt an, dass der Grund für den impliziten Datenfluss darin besteht, dass JS-Apps in ihren Anforderungen stark 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 abzurufen. Heute haben wir CORS (Cross-Origin Resource Sharing).

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

0
Lu55