ASP.NET Core MVC Authentifizieren Sie den Benutzer mit Azure AD, und erstellen Sie anschließend das JWT Bearer Token, um die Web-API aufzurufen

Ich erstelle eine ASP.NET-Core-Web-API , die durch Azure AD (gesichert über app.UseJwtBearerAuthentication )

Ich baue einen ASP.NET Core MVC Controller (gesichert durch app.UseOpenIdConnectAuthentication ), der diese WebAPI aufruft.

Ich versuche den Authentifizierungsablauf zu implementieren, wie im OpenID Connect Basic Client Implementer Handbuch beschrieben.

Der Beispielcode, den ich für dieses Muster finde.

Ein Beispiel ist hier:

  

/active-directory-dotnet-webapp-webapi-openidconnect/blob/master/TodoListWebApp/App_Start/Startup.Auth.cs)

verwendet .NET (nicht .NET Core ) mit OWIN .

Sie verwenden die Methode OnAuthorizationCodeReceived und rufen AcquireTokenByAuthorizationCodeAsynch auf, um das in Ihrer Anfrage verwendete Token an die WebAPI zu senden.

Wenn ich versuche, das analoge Muster in ASP.NET Core MVC zu erstellen, sehe ich Folgendes:

1. Wenn ich die App von MVC konfiguriere. UseOpenIdConnectAuthentication mit den Standardwerten, dann kann ich mich am System anmelden, bekomme aber keinen Autorisierungscode zurück. Das Ereignis, das für mich ausgelöst wird, ist das Ereignis OnTokenValidated anstelle des oben gezeigten Ereignisses AuthorizationCodeReceived . Es hat eine Identität und ein Token, was großartig ist.
2. Wenn ich die App von MVC konfiguriere. UseOpenIdConnectAuthentication response-type = “code” , dann bekomme ich einen Code zurück, das OnAuthorizationCodeReceived -Ereignis wird ausgelöst, aber ich bekomme keine Identität zurück.

[Mein azurblaues Anwendungsmanifest wurde für oauth2AllowImplicitFlow: true eingerichtet. In diesem Fall werden die Benutzerauthentifizierung und die Tokengenerierung in einem einzigen Schritt komprimiert, der nicht so sicher ist, wie ich es brauche, daher setze ich den Wert false.]

Nach weiteren Untersuchungen erfuhr ich, dass die Asp.Net Core -Infrastruktur für die Verwaltung mehrerer separater Authentifizierungs-Middleware-Einträge ausgelegt ist, und zwar

  

Microsoft.AspNetCore.Authentication.JwtBearer / JwtBearerHandler.cs

ist so codiert, dass ein Fehler "nicht zulässig" ausgegeben wird, wenn Sie versuchen, den SignIn -Workflow mit einer JwtBearer -Konfiguration zu verwenden.

Daher sieht es so aus, als müsste ich dem Ansatz der multiplen Middleware folgen. Eine cookie-basierte Middleware für den Login und eine träger-Token-basierte Middleware für den Bearer-Token für den Zugriff auf Dienste, die mit dieser App verknüpft sind. (Anstelle des Modells aus dem Beispiel OWIN , bei dem der Aufruf des Diensts nach Erhalt des Authentifizierungscodes erfolgt)

Diese Funktion (mehrere Authentifizierungs-Middlewares) wird in Ссылка

Hat jemand dafür ein Beispiel? Oder denke ich immer noch über dieses Unrecht nach?