Ich habe zwei Websites, eine Website, auf der sich Benutzer anmelden und deren Konto und Website ohne Benutzeroberfläche verwalten. Sie ist nicht mehr als eine API zum Speichern und Abrufen von Inhalten. Beide Websites verwenden dasselbe Owin ASP.Net Identity 2.0-Setup. Die UI-Site verwendet Cookies aus offensichtlichen Gründen und die API-Site verwendet Bearer-Token. Ich muss in der Lage sein, die API-Methoden / URLs von der UI-Site mit der aktuellen Benutzerauthentifizierung aufzurufen. Kurz gesagt, ich muss ein gültiges Bearer-Token in der UI-Site generieren, das zu den HTTP-Headern hinzugefügt wird, wenn die Rest-API-Aufrufe ausgeführt werden.
Ich suchte nach einer Möglichkeit, eine "vertrauenswürdige" Client-Authentifizierung zu verwenden und die / Token-URL aufzurufen, damit die API das Bearer-Token generiert, oder da beide Sites denselben Code und dieselbe Benutzertabelle verwenden, eine Owin-Methode zum Generieren der Bearer Token im Code der Benutzeroberfläche, die ich an die API-Header übergeben kann, und die API-Site sieht sie als gültiges Token.
Wenn Sie mehr Informationen brauchen, lassen Sie es mich wissen.
Update: Bitte beachten Sie die aktualisierte Antwort unten mit der korrekten Vorgehensweise, dies mit dem impliziten oAuth-Fluss zu tun.
Ich fand diesen Artikel schließlich und folgte seinem Beispielcode, um unseren eigenen OAuth Authorization Server zu erstellen. Damit können wir Benutzer-Tokens im Namen von Benutzern anfordern, die eine vertrauenswürdige Client-ID und geheime Schlüssel verwenden, die zwischen unserer Benutzeroberfläche und dem OAuth-Server ausgetauscht werden.
Update 1: Nachdem ich mehr mit der Funktionalität und den Dingen gearbeitet habe, bin ich über die Erstellung der Token gestolpert. Es gibt eine TicketDataFormat Klasse in Owin, die all die Magie ausübt. Es akzeptiert einen Parameter im Konstruktor und das ist ein IDataProtector . Wenn der Owin-Ressourcenserver das Standard-AccessTokenFormat ( TicketDataFormat ) in seinen Middleware-Optionen verwendet; Zusammen mit dem Standard DataProtector können Sie die Tokengenerierung auf Ihrer Clientseite replizieren. BTW, der Standard DataProtector verwendet den MachineKey, sodass Ihre beiden vertrauenswürdigen Sites in der Datei web.config denselben MachineKey aufweisen müssen. Alle nicht vertrauenswürdigen oder teilweise vertrauenswürdigen Sites sollten die standardmäßigen oAuth-Flows nutzen, die im obigen Link aufgeführt sind.
%Vor%Update 2: Die empfohlene und wirklich einzige Möglichkeit, dies zu tun, besteht darin, dass oAuth den Impliziten Fluss mit Ihrem Client verwendet, wobei die richtigen Bereiche und der richtige Antworttyp festgelegt sind.
Die IdentityServer3 Dokumentation enthält sehr gut dokumentierte Tutorials, die uns in kürzester Zeit zum Laufen brachten. Insbesondere die Aufruf der API im Auftrag von Abschnitt Erste Schritte: MVC-Authentifizierung & amp; Web APIs Tutorial.
Tags und Links owin asp.net-web-api2 asp.net-identity-2 bearer-token