Ich erstelle ein ASP.NET WebApi SPA mit OWIN-Middleware und benötige eine Erklärung, was die Eigenschaft AuthorizeEndpointPath in OAuthAuthorizationServerOptions tut.
In der Dokumentation steht
Der Anforderungspfad, über den Clientanwendungen den Benutzeragenten umleiten, um die Zustimmung des Benutzers zum Ausstellen eines Tokens zu erhalten. Muss mit einem führenden Schrägstrich wie "/ Autorisieren" beginnen.
Wenn ich versuche, auf ein geschütztes WebApi ohne Bearer-Token zuzugreifen, leitet meine Anwendung niemals (wie zu erwarten) auf den angegebenen Pfad um, sondern gibt einfach eine 401 zurück.
Danke.
Die verschiedenen Endpunktpfade dienen zur Verwendung mit verschiedenen OAuth-Flows für die Tokenvergabe.
TokenEndpointPath = Wird zum Abrufen von Token verwendet, in den Client-Berechtigungsnachweis gewähren -Fluss, den Ressourceneigner-Kennwortberechtigungsnachweis gewähren -Fluss und am Ende eines Berechtigungscode gewähren Fluss AuthorizeEndpointPath = Wird für die delegierte Berechtigung in der Autorisierungscode-Berechtigung flow und impliziter Erteilung flow Wenn Sie einen dieser Endpunkte aufrufen, werden in Ihrer Implementierung von OAuthAuthorizationServerProvider verschiedene Methoden ausgeführt. Welche Methoden ausgeführt werden, hängt davon ab, welchen Endpunkt Sie aufgerufen haben und welche Parameter Sie mit der Anforderung gesendet haben. Sie müssen einen von ihnen explizit von Ihrem Client aufrufen - Sie werden nie zu einem von beiden weitergeleitet werden.
Bevor wir die Flüsse und Endpunkte diskutieren, müssen wir zunächst drei Dinge definieren:
Wir lassen den Client direkt authentifizieren - wir bitten einen Benutzer nicht, überall einen Benutzernamen und ein Passwort einzugeben. Dies kann daran liegen, dass der Client keine Benutzer hat oder es uns egal ist, wer der Benutzer ist, wenn wir den Web-Service aufrufen.
Beispiel Anfrage:
%Vor% Ruft GrantClientCredentials (nach Überprüfung der Client-ID in ValidateClientAuthentication ) auf, damit Sie einige Ansprüche für den Client einrichten können.
Dies ist, wenn der Benutzer seine Details direkt in den Client eingibt und der Client diese Details direkt an den Autorisierungsserver sendet. So sieht der Client die Anmeldeinformationen des Benutzers .
Sie würden es in Ihrem Client mit einer Anfrage wie folgt aufrufen:
%Vor% Der Client stellt eine Anfrage an den Endpunkt, den Sie in TokenEndpointPath angegeben haben, mit grant_type des Passworts. Dies führt zu einem Aufruf der Methode GrantResourceOwnerCredentials in Ihrer Implementierung von OAuthAuthorizationServerProvider .
Unter der Annahme, dass die Benutzeranmeldeinformationen gültig sind, wird der Zugriff gewährt, Sie erstellen eine Identität, die bestimmte Ansprüche für diesen Benutzer hat, und es wird ein Token zurückgegeben, das der Client anschließend an den Autorisierungsserver senden kann, um diese Identität wieder herauszuholen spätere Anfragen.
Für den Autorisierungscode grant flow und den impliziten Grant -Fluss sind wir daran interessiert, wer der Benutzer ist, aber wir möchten nicht, dass der Benutzer Anmeldeinformationen direkt in den Client eingibt . In diesem Fall ruft der Client den Autorisierungsserver an, und der Autorisierungsserver veranlasst den Benutzer, sich im Auftrag des Clients zu authentifizieren. In diesem Fall muss der Client über seine Client-ID und eine redirect_url und einige andere Bits senden.
%Vor% Der Parameter response_type bestimmt, ob wir den impliziten oder Autorisierungscode -Fluss verwenden. In AuthorizationEndpointResponse basierend darauf können wir entweder das Token oder den Code zurückgeben. Wenn wir einen Code zurückgeben, muss der Client den TokenEndpointPath mit diesem Code aufrufen, um ein Token zu erhalten.
Sehen Sie sich dies an MSDN-Seite für weitere Informationen sowie Kapitel 16 von Entwerfen von erweiterbaren Web-APIs mit ASP.NET .
Ich bin hier auf der Suche nach der gleichen Antwort gelandet. Und da ich keine gefunden habe, habe ich angefangen, mit dem Decompiler zu graben.
Es stellt sich heraus, dass das OAuthAuthorizationServerMiddleware entweder TokenEndpointPath oder AuthorizeEndpointPath verwendet, um den aktuellen Anfrage-URI zu vergleichen und zu sehen, ob es sich um einen Authentifizierungsversuch handelt. Wenn es mit AuthorizeEndpointPath übereinstimmt, wird mit den Parametern von AuthorizeEndpointRequest ein neues this.Request.Query erstellt, das Werte wie client_id und redirect_uri enthalten sollte.
Also meine Vermutung ist, dass eine Anfrage an die AuthorizeEndpointPath wie
und würde offensichtlich verwendet werden authentifizieren mit einem Drittanbieter-Server.
Auch das kann ich aus dem Quellcode herausfinden.
Tags und Links asp.net-web-api owin asp.net-identity