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

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.

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 

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/

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.

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

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

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.