.Net Core 3.1JWTとOpenIDConnect認証のマージ

短いバージョン： .NET Core MVC Webサイトで正しい認証構成をマージして、ユーザーがAzure Active Directoryに対して認証できるようにするだけでなく、（コンソールアプリからの）デーモン接続も許可するのに問題があります。

長いバージョン： Startup.csのConfigureServicesメソッドで次を使用すると、Azure ActiveDirectoryに対して完全に正常に認証される.NETCore MVCWebサイトがあります。

 services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddSignIn("AzureAd", Configuration, options => Configuration.Bind("AzureAd", options));

また、.NET CoreコンソールアプリでAPIを（デーモン接続として）上記のMVC Webサイトに呼び出そうとしています（すべては、Microsoft Azureアカウントの[アプリの登録]セクションで構成されています）。コンソールアプリをMVCWebサイトに接続すると、コントローラーでアクション結果が正常にヒットしますが、WebサイトのStartup.csのConfigureServicesメソッドで以下を使用している場合に限ります。

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
   .AddProtectedWebApi("AzureAd", Configuration, options => Configuration.Bind("AzureAD", options));

基本的に、OpenIdConnectオプションのみを使用すると、WebユーザーはWebサイトにアクセスできますが、コンソールアプリは拒否されます。JwtBearerオプションのみを使用すると、コンソールアプリは接続できますが、Webユーザーは拒否されます。

私は一日中Google-Bingを使用していて、これら2つの構成のマッシュアップを他の構成をノックアウトせずに機能させるのに苦労しています。

.AddJwtBearer（）メソッドを使用しようとしましたが、完全に混乱しています。

services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
   .AddSignIn("AzureAd", Configuration, options => Configuration.Bind("AzureAd", options))
   .AddJwtBearer(options => Configuration.Bind("AzureAD", options));

これらはどのように連携して機能しますか？両方を配置でき、Webアプリはブラウザーを介して機能し、コンソールアプリ（デーモン）も機能しますか？両方をappsettings.jsonファイルにバインドできますか？

ちなみに、appsettings.jsonファイルは次のようになります。

{
  "AzureAd": {
  "Instance": "https://login.microsoftonline.com/",
  "Domain": "zzzzzzzzzzzzzz.onmicrosoft.com",
  "TenantId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy",
  "ClientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "CallbackPath": "/signin-oidc",
  "SignedOutCallbackPath ": "/signout-callback-oidc",
  "ClientSecret": "myAzureClientSecret"
  }
}

更新2020-06-15： AGESでこれをオン/オフして作業した結果、適切な解決策が見つかりました。そのため、@ michael-shterenbergに報奨金を授与します。また、@ gary-archerと彼の印象的なブログサイトから学ぶことがたくさんあることもわかりました。私はたまたまマイケルの意見から成功を収めました。

上の図のASP.NETCore MVCWebアプリ内のStartup.csファイルのmodは次のとおりです。

services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddSignIn("AzureAd", Configuration, options =>     
          Configuration.Bind("AzureAd", options))
            .AddJwtBearer(o =>
            {
                o.Authority = "https://login.microsoftonline.com/common";
                o.TokenValidationParameters.ValidateAudience = false;
                o.TokenValidationParameters.ValidateIssuer = false;
            });

services.AddAuthorization(options =>
    {
        options.AddPolicy("UserAndApp", builder =>
        {                    
             builder.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);

builder.AuthenticationSchemes.Add(OpenIdConnectDefaults.AuthenticationScheme);

             builder.RequireAuthenticatedUser();
        });
    });

...デーモンアプリから呼び出そうとしているコントローラーで次の属性を使用することと相まって。

[Authorize("UserAndApp")]

ユーザーは引き続きAzureActive Directoryプロセスを使用してWebサイトにログインでき、自動化されたプロセスでもログインできるようになりました。

これらすべてのAzureApp Registration側がどのように機能するかを理解するのに苦労している人がいる場合は、次の非常に説明的なブログ投稿を試してください。

BearerAuthenticationを使用して.NETCoreAPIを保護します

（以前、Azureアプリの登録プロセスがどのように機能するかを頭に入れようとしていたときにそれを見ていたらよかったのにと思います！）

これが私のために働いた解決策です（ASP .NET Core 2.1および3.1でテスト済み）

1. 2つのタイプ（CookieとJWT）があるため、デフォルトの認証スキームを設定しないでください。つまり、への呼び出しAddAuthenticationはパラメータなしである必要があります。

services.AddAuthentication()
   .AddAzureAD(options => Configuration.Bind("AzureAd", options))
   .AddJwtBearer(o=> {
       o.Authority = "https://login.microsoftonline.com/common";
       o.TokenValidationParameters.ValidateAudience = false;
       o.TokenValidationParameters.ValidateIssuer = false;
});

• / commonを権限（またはテナントID）に適用する必要があるため、AD構成を明示的にバインドしなかったことに注意してください。
• また、オーディエンスと発行者の検証をfalseに設定して、AADトークンがテストで機能するようにします。あなたは明らかに正しい聴衆/発行者を設定する必要があります

• 私は使用しましたがAddAzureAd、使用していませんAddSignIn（それはあなたが使用しているカスタム外部ライブラリですか？）

  1. 両方の認証スキームを受け入れるポリシーを作成します。

services.AddAuthorization(options =>
{
    options.AddPolicy("UserAndApp", builer =>
    {
        builer.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);
        builer.AuthenticationSchemes.Add(AzureADDefaults.AuthenticationScheme);

        builer.RequireAuthenticatedUser();
    });
});

• これを既存の認証設定に置き換えます
  1. コントローラで新しいポリシー名を使用します。

[Authorize("UserAndApp")]
public class HomeController : Controller

力学に関するいくつかの説明：

自動認証スキームを設定する必要はありません。これは、2つの異なるタイプがある一方で、認証ミドルウェアで実行されるデフォルトのスキーマになるためです。

ポリシーは両方の認証ハンドラーを実行しようとします。一方が成功した場合、認証は成功しました。

注：無効なベアラートークンを使用してリクエストを送信すると、両方の認証ハンドラーが失敗します。この場合、AzureADDefaults実際にチャレンジメソッドを実装し、リダイレクトするため（ステータスコード302）、「勝ち」ます。これを必ず処理してください。あなたのアプリで

アーキテクチャが完全に正しくないように感じます。Webバックエンドによって実行される2つの役割を分離する必要があります。

現在のWebのみのアーキテクチャ

• 認証Cookieを使用するWebUIフロントエンドがあります
• ビューリクエストにCookieを必要とするWebバックエンドがあります
• APIリクエストにCookieを必要とするWebバックエンドがあります
• Cookieを使用できないため、APIエントリポイントを呼び出すことができないコンソールクライアントがあります

マルチクライアントアーキテクチャ

Webバックエンドを更新して、CookieではなくOAuth2.0アクセストークンで保護されているAPIエントリポイントを含める必要があります。これで、コンソールアプリはWebバックエンドを呼び出すことができるようになります。

.NET CORE SUB PATHS

Webバックエンドに追加の/ apiサブパスを導入します。UseWhenの機能を使用すると、他のウェブバックエンドの動作に影響を与えることなく、これを行うことができます：

/*
 * Apply API behaviour to only subpaths, without impacting the rest of the app
 */ 
app.UseWhen(
ctx => ctx.Request.Path.StartsWithSegments(new PathString("/api")),
api => {
  api.useAuthentication();
  api.useJwtBearer();
});

.NET COREAPIの例

サブパスを使用する例については、サンプルの.Net CoreAPIを参照してください。起動クラスは、 ASP.Netのミドルウェアが異なるサブパスのための異なるauthenticaitonの取り扱いに配線されているところです。

将来の可能性

上記の論理的な分離ができたら、将来的にはさらに進化させることができます。たとえば、完全にCookieのないモデルになります。

• トークンのみに基づいて完全に独立したコンポーネントとしてAPIを開発する
• WebUIをクライアント側のセキュリティライブラリを使用するSPAに更新します

私のブログ https://authguidance.com このアプローチに従い、私のサンプルAPIはすべてあらゆるタイプのクライアントをサポートします。