ASP.NET CoreでDefaultSchemeとDefaultChallengeSchemeを構成するポイントは何ですか？

Question

ASP.NET Core 2.0およびIdentityServer4でセキュリティがどのように機能するかを学習しています。 IdentityServer、API、およびASP.NET Core MVCクライアントアプリを使用してプロジェクトを設定しました。

以下のように、クライアントアプリのConfigureServiceメソッド。ここでは、DefaultSchemeとDefaultChallengeSchemeについて混乱しています。それらを構成するポイントは何ですか？それがどのように機能するかについての詳細な説明は、可能であれば本当に役立ちます。

DefaultSchemeの代わりにすでに見ましたが、DefaultSignInSchemeも機能しますが、どのように機能しますか？それらの違いは何ですか？

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

    services.AddAuthentication(options =>
    {
        options.DefaultScheme = "Cookies";
        options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
        //options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        //options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
    })
    .AddCookie("Cookies")
    .AddOpenIdConnect(OpenIdConnectDefaults.AuthenticationScheme, options =>
    {
        options.SignInScheme = "Cookies";
        options.RequireHttpsMetadata = false;

        options.Authority = "http://localhost:5000/";
        options.ClientId = "mvcclient";
        options.SaveTokens = true;
    });
}

Answer 1

まず、ASP.NET Core Identityを使用していないことに注意してください。 IDは、認証システムの上部にあるを構築するユーザー管理スタックです。 IdentityServerをプロバイダーとしてOpenID Connectを使用しているように見えるため、WebアプリケーションはOIDC情報のみを消費し、独自のIDを管理する必要はありません（IdentityServerがASP.NET Core Identityを使用している可能性もあります）。

ASP.NET Coreで認証スタックが機能する方法は、一連の認証スキームを構成できることです。これらのスキームの一部は、組み合わせて使用​​することを目的としています。たとえば、Cookie認証スキームが単独で使用されることはほとんどありませんが、完全に分離して使用できるスキームもあります（JWTベアラー認証など）。

認証アクション

認証の世界では、実行できる特定のアクションがあります。

• Authenticate：基本的に、認証とは、指定された情報を使用して、その情報でユーザーを認証することを意味します。したがって、これはユーザーIDを create してフレームワークで使用できるようにします。

  たとえば、Cookie認証方式はCookieデータを使用してユーザーIDを復元します。または、JWTベアラー認証スキームは、リクエストのAuthorizationヘッダーの一部として提供されるトークンを使用して、ユーザーIDを作成します。

• Challenge：認証スキームが要求されると、スキームはユーザーに自分自身を認証するように要求する必要があります。これは、たとえば、ユーザーがログインフォームにリダイレクトされることや、外部認証プロバイダーにリダイレクトされることを意味します。

• Forbid：認証スキームが禁止されている場合、スキームは基本的に、ユーザーが実行しようとしたことは何もできないことをユーザーに通知するもので応答します。これは通常 HTTP 4 エラーであり、いくつかのエラーページへのリダイレクトである可能性があります。

• Sign-in：認証スキームがサインインされると、既存のユーザー（a ClaimsPrincipal ）そしてそれを何らかの方法で持続させる。たとえば、Cookie認証方式でユーザーをサインインすると、基本的にはそのユーザーのIDを含むCookieが作成されます。

• Sign-out：これはサインインの逆であり、基本的には認証スキームにその永続性を削除するように指示します。 Cookieスキームにサインアウトすると、Cookieが有効期限切れになります。

すべての認証方式がすべてのオプションを実行できるわけではないことに注意してください。サインインとサインアウトは通常、特別なアクションです。 Cookie認証スキームはサインインとサインアウトをサポートする例ですが、たとえばOIDCスキームはそれを行うことができませんが、サインインしてIDを保持するために別のスキームに依存します。そのため、通常はCookieスキームも表示されます。

一般的な認証フロー

認証スキームは明示的に使用できます。 HttpContext で 認証拡張メソッドの1つ、たとえば_ {（httpContext.AuthenticateAsync() を使用する場合は、どの認証スキームをいつでも明示的に指定できますこの操作に使用したい。

したがって、たとえば、Cookie認証スキーム"Cookie"でサインインする場合は、コードから次のように呼び出すだけです。

 var user = new ClaimsPrincipal(…);
 await httpContext.SignInAsync(user, "Cookie");

しかし実際には、認証を直接かつ明示的に呼び出すことは、最も一般的なことではありません。代わりに、通常はフレームワークに依存して認証を行います。そしてそのために、フレームワークはどの認証スキームをどの操作に使用するかを知る必要があります。

それが AuthenticationOptions の目的です。これらのオプションを構成して、これらの各認証アクションのデフォルトとして使用する認証スキームを明示的に定義できるようにすることができます。

• DefaultAuthenticateScheme ：認証時に使用するデフォルトのスキームを設定します。
• DefaultChallengeScheme ：チャレンジ時に使用するデフォルトのスキームを設定します。
• DefaultForbidScheme ：アクセスが禁止されている場合に使用するデフォルトのスキームを設定します。
• DefaultSignInScheme ：デフォルトのスキームをサインインに設定します。
• DefaultSignOutScheme ：ログアウトするデフォルトのスキームを設定します。
• DefaultScheme ：デフォルトのフォールバックスキームを設定します（以下を参照）。

通常、 all これらのプロパティは設定しません。代わりに、フレームワークにはデフォルトのフォールバックがいくつかあるため、これらのプロパティのサブセットのみを構成できます。ロジックは次のとおりです。

• 認証：DefaultAuthenticateScheme、またはDefaultScheme
• チャレンジ：DefaultChallengeScheme、またはDefaultScheme
• 禁止：DefaultForbidScheme、またはDefaultChallengeScheme、またはDefaultScheme
• サインイン：DefaultSignInScheme、またはDefaultScheme
• サインアウト：DefaultSignOutScheme、またはDefaultScheme

ご覧のとおり、特定のアクションのデフォルトが設定されていない場合、各認証アクションはDefaultSchemeにフォールバックします。したがって、通常表示されるのはDefaultSchemeが構成されていることであり、次に、別のスキームが必要なアクションに対して特定のアクションが構成されます。

あなたの例はこれをかなりよく示しています：OIDCでは、外部認証プロバイダーによって提供されるIDを永続化できるサインインスキームが必要になります。したがって、通常はOIDCおよびCookie認証スキームが表示されます。

services.AddAuthentication(options =>
{
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
.AddCookie()
.AddOpenIdConnect(options =>
{
    options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
});

ユーザーの場合、通常の対話はCookie認証スキームを介して行われます。ユーザーがWebアプリケーションにアクセスすると、Cookie認証スキームはCookieを使用して認証を試みます。したがって、すべての操作のデフォルトスキームとしてCookie認証スキームを使用します。

例外は認証に挑戦する場合です。その場合、ユーザーをOIDCプロバイダーにリダイレクトして、ユーザーがそこでログインしてIDで戻ることができるようにします。したがって、デフォルトの challenge スキームをOIDCスキームに設定します。

さらに、OIDCスキームとCookieスキームをリンクします。ユーザーがチャレンジを受けて外部認証プロバイダーにログインすると、外部IDを使用してWebアプリケーションに送り返されます。ただし、OIDCスキームはそのIDを永続化できないため、 using 別のスキーム（Cookieスキーム）を使用してサインインし、OIDCスキームに代わってIDを永続化します。 Cookieスキームを設定すると、OIDC IDのCookieが作成され、次のリクエストで、Cookieスキーム（デフォルトのスキーム）がそのCookieを使用してユーザーを再度認証できるようになります。

---

そのため、ほとんどの場合、デフォルトのスキームを指定するだけで問題なく、認証設定に応じて、1つまたは2つの明示的なアクションを変更できます。しかし理論的には、さまざまなデフォルトと複数のスキームの非常に複雑なセットアップを完全にセットアップできます。フレームワークにより、ここで多くの柔軟性が得られます。