wake-up-neo.com

IdentityServer Flows

IdentityServer unterstützt verschiedene OpenId Connect-Flows, die in der Enumeration Flows definiert und für Clients festgelegt sind. Es gibt auch Beispiele für jeden Flusstyp und viele Verweise darauf in den Dokumenten, aber ich konnte keine einfache Definitionsliste der Flüsse in Dokumentation finden, als ob sie zu offensichtlich wären, um in Worten erklärt zu werden. Aber ich denke, das sind sie nicht. Kannst du bitte mehr über die Unterschiede erzählen, vielleicht können wir das den Dokumenten hinzufügen?

Also, was sind: impliziter Fluss, Passwort des Ressourcenbesitzers Fluss, Autorisierungscode Fluss, Clientanmeldeinformationen Fluss, Custom Grant Flow und Hybrid Flow? Auch welche sind OAuth Flows und welche sind OpenID Connect Flows?

Vielen Dank!

53
orad

Ich hatte das gleiche Problem, derzeit sind die Arbeiten noch im Gange. Wenn ich die Dokumentation fertig habe, kann ich sie hier posten. vorerst: bitte überprüfen sie den entwurf:

Bereichern Sie die IdentityServer-Dokumentation mit Abschnitt # 73 zu OIDC- und OAuth2-Flows.

Update: OIDC und OAuth2 Flows

38
Jawad Al Shaikh

Aus LeastPrivilage's erstem Link: und Aharon Paretzki's OAuth 2 Simplified

Die Flüsse entscheiden, wie der ID-Token (dh der Autorisierungscode) und der Zugriffstoken (dh 'das Token') werden an den Client zurückgegeben:

Authorization Code Flow : OAuth 2.0 flow in dem

  • ein Autorisierungscode wird vom Autorisierungsendpunkt zurückgegeben
  • und alle Token (als zweite Stufe im Austausch gegen den Autorisierungscode) werden vom Token-Endpunkt zurückgegeben
  • Wird für serverbasierte Aufrufe (APIs) verwendet, die die Vertraulichkeit ihres Clientgeheimnisses gewährleisten können. Ermöglicht eine stärkere Sicherheit, solange niemand auf das "Client-Geheimnis" zugreifen kann.

Impliziter Fluss : OAuth 2.0 flow in dem

  • alle Token werden direkt vom Autorisierungsendpunkt zurückgegeben
  • und weder der Token-Endpunkt noch ein Autorisierungscode werden verwendet.
  • Wird für mobile und webbasierte Apps verwendet, bei denen die Vertraulichkeit des Clientgeheimnisses nicht gewährleistet ist. Daher muss das Token vom Authentifizierungsserver selbst ausgestellt werden. Dies ist weniger sicher, und es wird empfohlen, dass der Server so eingestellt ist, dass impliziter Datenfluss Aufrufe für die API-Verwendung verweigert und nur für browserbasierte und mobilbasierte Apps zugelassen wird.

Hybrid Flow : OAuth 2.0 flow in dem

  • ein Autorisierungscode wird vom Autorisierungsendpunkt zurückgegeben.
  • einige Token werden direkt vom Autorisierungsendpunkt zurückgegeben, andere (als zweite Stufe im Austausch gegen den Autorisierungscode) vom Tokenendpunkt.
  • Wird verwendet, wenn beide Flüsse benötigt werden.
20
pashute

siehe die technischen Daten - alles wurde bereits niedergeschrieben:

http://openid.net/specs/openid-connect-core-1_0.html und http://tools.ietf.org/html/rfc6749

zusätzlich habe ich kürzlich eine Zusammenfassung geschrieben, die es für verschiedene Anwendungstypen aufschlüsselt:

http://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/

10
leastprivilege

Die in OAuth2 definierten Flüsse sind nur einige Möglichkeiten für einen Client, ein access token von einem Identitätsanbieter-Server zu empfangen. das IdentityServer in diesem Fall. Das Verständnis der Abläufe ist nur dann einfach, wenn Sie die in den Ablaufdiagrammen angegebenen Entitäten wie Resource Owner, User Agent und Resource Server. Es gibt einige kurze Erklärungen zu diesen Entitäten (Rollen, kostbar) in hier .


Authorization Code Flow : Gibt ein authorization code aus, bevor ein access token ausgegeben wird.

  • Ein Client fordert ein authorization code. an
  • IdentityServer Überprüft den Client und fordert den Ressourcenbesitzer auf, die Berechtigung zum Ausstellen eines authorization code zu erteilen.
  • Der Client fordert dann ein access token mit dem angegebenen authorization code an.
  • Der Autorisierungsserver gibt ein access token direkt an den Client aus.

Impliziter Codefluss : Gibt ein access token aus, auch wenn kein authorization code angegeben ist.

  • Ein Client fordert direkt ein access token an.
  • IdentityServer überspringt die Überprüfung des Clients (in einigen Szenarien teilweise), fordert den Ressourcenbesitzer jedoch weiterhin auf, die Berechtigung zum Ausstellen eines access token zu erteilen.
  • Dieser Ablauf gibt niemals ein authorization code aus.

Der implizite Ablauf wird als idealer Ablauf für einen Client angesehen, der Skriptsprachen wie javascript verwendet, da der Client kein Anfordern eines authorization code und access token getrennt voneinander, wodurch sich die Netzwerkumlaufzeit für den Client verringert.


Clientanmeldeinformationen fließen : Gibt ein access token ohne die Erlaubnis eines Ressourcenbesitzers aus.

  • Ein Client fordert direkt ein Zugriffstoken an.
  • IdentityServer validiert den Client und gibt sofort ein access token aus.

Dies ist ideal, wenn der Client auch ein Ressourcenbesitzer ist und daher bis zum access token keine Autorisierungsberechtigungen benötigt.


Ressourcenbesitzerfluss : Gibt ein access token aus, wenn ein Client über die Anmeldeinformationen des Ressourcenbesitzers verfügt (z. B. ID/Passwort).

  • Ein Client fordert direkt ein access token an.
  • IdentityServer überprüft den Client und die Identität des Ressourcenbesitzers.
  • Falls gültig, erhält der Client sofort access token.

Dieser Fluss ist ideal für die Kunden, die glauben, dass es absolut sicher ist, die IDs und Passwörter mit ihnen zu teilen.


Hybridfluss (OIDC-Fluss) : Gibt ein authorization code und ein access token aus.

Dies ist eine Kombination aus Authorization code flow und Implicit code flow. Deshalb heißt es Hybrid.


Benutzerdefinierter Ablauf

Dies ist buchstäblich ein anpassbarer Ablauf. Dies kann verwendet werden, wenn Sie in Ihrem Unternehmen einen bestimmten Authentifizierungs-/Validierungsprozess neben allen Protokollspezifikationen in OAuth2 benötigen.

IdentityServer ist sich dieser Situation bewusst und unterstützt Erweiterungsmöglichkeiten. Das Factory-Pattern, das Decorator-Pattern und IoC/DI erleichtern Ihnen die Implementierung zusätzlicher Funktionen auf Ihrem IdentityServer.

6
hina10531