wake-up-neo.com

Was ist der Unterschied zwischen den 2 Workflows? Wann wird der Autorisierungscode-Fluss verwendet?

OAuth 2.0 verfügt über mehrere Workflows. Ich habe ein paar Fragen zu den beiden.

  1. Autorisierungscodefluss - Benutzer meldet sich über die Client-App an. Der Autorisierungsserver gibt einen Autorisierungscode an die App zurück. Die App tauscht dann den Autorisierungscode für das Zugriffstoken aus.
  2. Impliziter Genehmigungsablauf - Benutzer meldet sich über die Client-App an, der Autorisierungsserver gibt ein Zugriffstoken direkt an die Client-App aus.

Was ist der Unterschied zwischen den beiden Ansätzen hinsichtlich der Sicherheit? Welches ist sicherer und warum? 

Ich sehe keinen Grund, warum in einem Arbeitsablauf ein zusätzlicher Schritt (Berechtigungscode für Token austauschen) hinzugefügt wird, wenn der Server ein Access-Token direkt ausgeben kann.

Verschiedene Websites geben an, dass der Autorisierungscode-Fluss verwendet wird, wenn die Client-App die Anmeldeinformationen sicher halten kann. Warum?

140
divyanshm

Der access_token ist das, was Sie benötigen, um eine geschützte Ressource (eine API) aufzurufen. Im Authorization Code-Fluss gibt es zwei Schritte, um ihn zu erhalten:

  1. Der Benutzer muss sich authentifizieren und gibt eine code an den API-Consumer (als "Client" bezeichnet) zurück.
  2. Der "Client" der API (normalerweise Ihr Webserver) tauscht die in # 1 erhaltene code mit einem access_token aus und authentifiziert sich mit einem client_id und client_secret.
  3. Sie kann dann die API mit dem access_token aufrufen.

Es gibt also eine doppelte Überprüfung: Der Benutzer, dem die Ressourcen gehören, die über eine API aufgetaucht sind, und der Client, der die API verwendet (z. B. eine Web-App). Beide sind für die Erteilung des Zugangs validiert. Beachten Sie die Autorisierungseigenschaften von OAuth hier: Der Benutzer gewährt einer App Zugriff auf seine Ressource (über die nach der Authentifizierung zurückgegebene code), die App erhält einen access_token und ruft im Namen des Benutzers auf.

In dem impliziten Fluss wird Schritt 2 ausgelassen. Nach der Benutzerauthentifizierung wird also direkt ein access_token zurückgegeben, den Sie für den Zugriff auf die Ressource verwenden können. Die API weiß nicht, wer diese API aufruft. Jeder mit dem access_token kann dies, während im vorherigen Beispiel nur die Web-App dies tun würde (Interna sind normalerweise für niemanden zugänglich).

Der implizite Fluss wird normalerweise in Szenarien verwendet, in denen das Speichern von client id und client secret nicht empfohlen wird (z. B. ein Gerät, obwohl viele es trotzdem tun). Das ist der Disclaimer. Benutzer haben Zugriff auf den Clientcode und können daher die Berechtigungsnachweise erhalten und so tun, als würden sie Ressourcenclients. Im impliziten Fluss sind alle Daten flüchtig und es wird nichts in der App gespeichert.

180
Eugenio Pace

Ich füge hier etwas hinzu, von dem ich glaube, dass es in den obigen Antworten nicht klar ist:

  • Der Authorization-Code-Flow ermöglicht, dass das endgültige Zugriffstoken niemals mit dem Browser/der App auf dem Computer erreicht und niemals gespeichert wird. Der temporäre Autorisierungscode wird mit dem Browser/der App an den Computer übermittelt, der dann an einen Server gesendet wird. Der Server kann es dann mit einem vollständigen Zugriffstoken austauschen und hat Zugriff auf APIs usw. Der Benutzer mit dem Browser erhält Zugriff auf die API nur über den Server mit dem Token.
  • Der implizite Fluss kann nur zwei Parteien umfassen, und das endgültige Zugriffstoken wird auf dem Client mit dem Browser/der Anwendung gespeichert. Wenn dieser Browser/diese Anwendung gefährdet ist, ist das zugehörige Auth-Token gefährlich.

tl; dr verwendet keinen impliziten Fluss, wenn Sie nicht darauf vertrauen, dass der Computer des Benutzers Token enthält, Sie jedoch do Ihren eigenen Servern vertrauen.

49
George Powell

Der Unterschied zwischen beiden ist der:

  1. Im impliziten Fluss wird das Token direkt über die Umleitungs-URL mit dem Zeichen "#" zurückgegeben. Dieses Token wird hauptsächlich in Javascript-Clients oder mobilen Anwendungen verwendet, die keine eigene Serverseite haben, und der Client muss bei einigen Implementierungen sein Geheimnis nicht angeben .

  2. Im Berechtigungscode wird der Code mit "?" Zurückgegeben. Um serverseitig lesbar zu sein, muss der Server diesmal Token-URL mit Client-Secret angeben, um das Token als Json-Objekt vom Autorisierungsserver abzurufen. Sie wird verwendet, wenn Sie über einen Anwendungsserver verfügen, der damit umgehen kann und das Benutzer-Token mit seinem/ihrem Profil auf seinem eigenen System speichert und meist für gängige mobile Anwendungen verwendet wird.

es hängt also von der Art Ihrer Clientanwendung ab, welcher sicherere "Autorisierungscode" ist, da er das Geheimnis auf Client und das Token anfordert, und zwar zwischen dem Autorisierungsserver und der Clientanwendung bei einer sehr sicheren Verbindung und dem Autorisierungsanbieter Einige Clients dürfen nur "Autorisierungscode" verwenden und implizit nicht zulassen 

13

Die implizite Erteilung ähnelt der Erteilung des Autorisierungscodes mit zwei unterschiedlichen Unterschieden.

Es soll für Benutzeragenten-basierte Clients (z. B. einseitige Web-Apps) verwendet werden, die einen Client nicht geheim halten können, da der gesamte Anwendungscode und der Speicher leicht zugänglich sind.

Zweitens gibt der Autorisierungsserver nicht einen Autorisierungscode zurück, der gegen ein Zugriffstoken ausgetauscht wird, sondern der Berechtigungsserver gibt ein Zugriffstoken zurück.

Details finden Sie hier http://oauth2.thephpleague.com/authorization-server/which-grant/

3
Lutfor

Lassen Sie mich die Punkte zusammenfassen, die ich aus den obigen Antworten gelernt habe, und einige meiner eigenen Erkenntnisse hinzufügen.

Autorisierungscode-Fluss !!!

  • Wenn Sie einen Webanwendungsserver haben, der als OAuth-Client fungiert
  • Wenn Sie einen langlebigen Zugang haben möchten
  • Wenn Sie offline auf Daten zugreifen möchten
  • wenn Sie für API-Anrufe verantwortlich sind, die Ihre App durchführt
  • Wenn Sie Ihr OAuth-Token nicht verlieren möchten
  • Wenn Sie nicht möchten, dass Ihre Anwendung jedes Mal, wenn sie Zugriff auf Daten benötigt, den Berechtigungsfluss durchläuft. ANMERKUNG: Der Implicit Grant-Ablauf enthält kein Aktualisierungstoken. Wenn also der Berechtigungsserver regelmäßig Zugriffstoken ausführt, muss Ihre Anwendung den Berechtigungsablauf durchlaufen, wenn er Zugriff benötigt. 

Impliziter Förderfluss !!!

  • Wenn Sie nicht über einen Webanwendungsserver verfügen, der als OAuth-Client fungiert
  • Wenn Sie keinen langlebigen Zugriff benötigen, ist nur ein temporärer Zugriff auf Daten erforderlich.
  • Wenn Sie dem Browser, in dem Ihre App ausgeführt wird, vertrauen und nur begrenzte Bedenken bestehen, dass das Zugriffstoken an nicht vertrauenswürdige Benutzer verloren geht.
1
Aman Tuladhar

Impliziter Fluss

Vorteile

  • Am einfachsten zu implementieren

Nachteile

  • Zugriffstoken für den Browser sichtbar
  • Der Ursprung der Zugriffstoken kann nicht bestimmt werden
  • Zugriffstoken können nicht verfallen (durch Google-Richtlinien)

Berechtigungscode-Fluss

Vorteile

  • Am sichersten
  • Zugriffstoken und Aktualisierungstoken können nur erstellt werden, wenn ein gemeinsames Geheimnis bekannt ist
  • Kann mit neuen Sicherheits- und UX-Funktionen erweitert werden, sobald sie verfügbar sind

Nachteile

  • Es müssen mehrere Authentifizierungsendpunkte implementiert werden

Zitierung: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

1
vlazzle

Welches ist sicherer und warum?

Beide sind sicher, es hängt von der Umgebung ab, in der Sie es verwenden.

Ich sehe keinen Grund, warum in einem Arbeitsablauf ein zusätzlicher Schritt (Berechtigungscode Für Token austauschen) hinzugefügt wird, wenn der Server direkt ein Access-Token ausgeben.

Es ist einfach. Ihr Kunde ist nicht sicher. Lassen Sie uns es im Detail sehen. 

Stellen Sie sich vor, Sie entwickeln eine Anwendung für Instagram API. Registrieren Sie Ihre APP mit Instagram und definieren Sie, welchen API's Sie benötigen. Instagram liefert Ihnen client_id und client_secrect

Auf Ihrer Website haben Sie einen Link eingerichtet, auf dem steht. Msgstr "Kommen Sie und verwenden Sie meine Anwendung". Wenn Sie darauf klicken, sollte Ihre Webanwendung zwei Aufrufe an Instagram API ausführen.

First Sende eine Anfrage mit den folgenden Parametern an Instagram Authentication Server.

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

Sie senden nicht client_secret, Sie konnten dem Client nicht vertrauen (der Benutzer und/oder sein Browser, der versucht, Ihre Anwendung zu verwenden). Der Client kann die URL oder das Java-Skript sehen und Ihren client_secrect leicht finden. Deshalb brauchen Sie einen weiteren Schritt.

Sie erhalten eine code und eine state. Die code ist hier temporary und wird an keiner Stelle gespeichert.

Dann machen Sie einen second-Aufruf an Instagram API (von Ihrem Server).

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

Da der Aufruf von unserem Server aus erfolgt, können wir client_secret (was zeigt, wie wir sind) mit code verwenden, wodurch der Benutzer client_id die Verwendung der Ressource gewährt hat.

Als Antwort haben wir access_token

0
Alireza Fattahi

Aus praktischer Sicht (Was ich verstanden habe), ist der Hauptgrund für den Authz-Code-Fluss:

  1. Unterstützung für Aktualisierungstoken (langfristiger Zugriff durch Apps im Auftrag des Benutzers), implizit nicht unterstützt: siehe: https://tools.ietf.org/html/rfc6749#section-4.2
  2. Unterstützung für die Einwilligungsseite. Hier kann der Ressourcenbesitzer steuern, welcher Zugriff bereitgestellt werden soll (Art der Berechtigungs Autorisierungsseite, die Sie in Google sehen). Gleiches ist nicht implizit vorhanden. Siehe Abschnitt: https://tools.ietf.org/html/rfc6749#section-4.1 , Buchstabe B

"Der Autorisierungsserver authentifiziert den Ressourceninhaber (über den Benutzeragenten) und legt fest, ob der Ressourceninhaber die Zugriffsanforderung des Clients erteilt oder verweigert."

Darüber hinaus können Apps mithilfe von Aktualisierungs-Token langfristigen Zugriff auf Benutzerdaten erhalten.

0
dvsakgec