Ich habe die letzten Tage damit verbracht, alle Spezifikationen bezüglich OAuth2 und OpenIDConnect durchzulesen und einen Testclient mit Thinktecture Identity Server zu implementieren. Ich habe auch mehrere Kurse besucht, und ich glaube, ich verstehe den Hauptgrund. Allerdings bin ich immer noch sehr verwirrt über die Antworttypen.
OpenIDConnect-Spezifikation gibt an, dass die hybriden Flow-Antworttypen eine Kombination aus "Code", "id_token" und "Token" sind. Ich verstehe, dass das "id_token" uns erlaubt, anfänglich Zugang zu grundlegenden Identifikationsinformationen zu bekommen.
Ich verstehe auch Code "bezieht sich auf den Autorisierungscode und" Token "bezieht sich auf ein Access-Token und Kombination" Code "mit einem oder beiden der beiden anderen löst den Fluss, aber mein Verständnis war, dass Sie einen Autorisierungscode für eine Zugriffstoken im Autorisierungsablauf, während der implizite Fluss den Zugriffscode implizit bereitstellt?
Könnte jemand meine Verwirrung klären?
Die folgenden Aussagen, die Sie getroffen haben, sind korrekt:
code bezieht sich auf den Autorisierungscode token bezieht sich auf ein Access Token oder ( access_token ) code für einen access_token
Aber ein Teil Ihrer Verwirrung kann aus dem Verwechseln von Terminologie herrühren:
Wie @juanifioren darauf hingewiesen hat, kombinieren hybride Flüsse Dinge:
code id_token -Fluss würde direkt eine code und id_token in der Authentifizierungsantwort erhalten, aber Sie würden code verwenden, um access_token vom Token-Endpunkt code token -Fluss würde direkt eine code und access_token in der Authentifizierungsantwort erhalten, aber Sie würden code verwenden, um eine id_token und möglicherweise eine weitere access_token im Backend vom Token zu erhalten Endpunkt code id_token token -Fluss würde eine code , access_token und eine id_token in der Authentifizierungsantwort direkt erhalten und Sie könnten code im Backend verwenden, um ein anderes access_token vom Token-Endpunkt Das Abrufen eines access_token vom Token-Endpunkt unterscheidet sich davon, ob es vom Autorisierungsendpunkt abgerufen wird, da sich die vertraulichen Clients beim Token-Endpunkt (und nicht beim Autorisierungsendpunkt) authentifizieren. Daher kann die access_token für den vertraulichen Teil des Clients mehr Berechtigungen und / oder eine längere Lebensdauer haben.
Siehe auch einen kurzen Thread auf der Spec-Mailingliste zu diesem Thema: Ссылка
Informationen zu den möglichen Beziehungen zwischen Antworttypen und Grant-Typen finden Sie unter IdentityServer4 \ Constants.cs
%Vor%Ihre Gedanken zum Autorisierungscodefluss und zum impliziten Fluss sind richtig. Aber ich denke, dass Sie den hybriden Fluss übermäßig komplizieren. Wenn Sie hybrid verwenden, können Sie einfach Code und id_token bekommen.
Danach können Sie entweder Code greifen und ihn für das Zugriffstoken austauschen oder einfach das id_token (oder Zugriffstoken) direkt verwenden. Beide Ansätze haben ihre eigenen Schwächen, insbesondere in Bezug auf die Sicherheit.
Tags und Links asp.net-web-api asp.net oauth-2.0 openid-connect