在ASP.NET Core上配置DefaultScheme和DefaultChallengeScheme有什么意义?

本文介绍了在ASP.NET Core上配置DefaultScheme和DefaultChallengeScheme有什么意义?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在学习安全性如何在ASP.NET Core 2.0和IdentityServer4上工作.我使用IdentityServer，API和ASP.NET Core MVC客户端应用程序设置了项目.

I am learning how security works on ASP.NET Core 2.0 and IdentityServer4. I set up the projects with IdentityServer, API and ASP.NET Core MVC Client App.

ConfigureService方法，如下所示.在这里，我在DefaultScheme和DefaultChallengeScheme上感到困惑.配置这些的重点是什么?如果可能的话，对其进行详细的描述将非常有帮助.

ConfigureService method on Client App as in below. Here I am confusing on DefaultScheme and DefaultChallengeScheme. What is the point of configuring those? A detailed description on how it works would be really helpful if possible.

我已经看到了DefaultSignInScheme而不是DefaultScheme，但是它如何工作?这些有什么区别?

I already seen instead of DefaultScheme, DefaultSignInScheme also works, but how does it work? What is the difference of those?

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;
    });
}

典型身份验证流程

可以明确使用身份验证方案.当您使用身份验证之一时HttpContext 上的扩展方法，例如 httpContext.AuthenticateAsync() ，那么您始终可以明确指定要用于此操作的身份验证方案.

Typical authentication flow

Authentication schemes can be used explicitly. When you use one of the authentication extension methods on the HttpContext, for example httpContext.AuthenticateAsync(), then you can always explicitly specify what authentication scheme you want to use for this operation.

例如，如果您想使用cookie身份验证方案"Cookie"登录，则可以从代码中像这样简单地调用它:

So if you, for example, want to sign in with the cookie authentication scheme "Cookie", you could simply call it like this from your code:

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

但是在实践中，最直接的事情就是直接直接地进行身份验证.取而代之的是，您通常将依赖于框架为您执行身份验证.为此，框架需要知道对哪种操作使用哪种身份验证方案.

But in practice, calling the authentication directly and explicitly like that is not the most common thing to do. Instead, you will typically rely on the framework to do authentication for you. And for that, the framework needs to know which authentication scheme to use for what operation.

这就是 AuthenticationOptions 用于.您可以配置这些选项，以便可以显式定义将哪些身份验证方案用作这些身份验证操作的默认身份验证:

That is what the AuthenticationOptions are for. You can configure those options so that you can explicitly define what authentication scheme to use as the default for each of those authentication actions:

:设置身份验证时使用的默认方案.
:设置挑战时使用的默认方案.
:设置禁止访问时使用的默认方案.
:设置默认的登录方案.
:设置默认方案以退出.
:设置默认的后备方案(请参见下文).

DefaultAuthenticateScheme: Sets the default scheme to use when authenticating.
DefaultChallengeScheme: Sets the default scheme to use when challenging.
DefaultForbidScheme: Sets the default scheme to use when access is forbidden.
DefaultSignInScheme: Sets the default scheme to sign in.
DefaultSignOutScheme: Sets the default scheme to sign out.
DefaultScheme: Sets the default fallback scheme (see below).

您通常不会配置 all 所有这些属性.相反，该框架具有一些默认的后备，因此您可以仅配置这些属性的一部分.逻辑是这样的:

You typically don’t configure all those properties. Instead, the framework has some default fallbacks, so you can configure just a subset of those properties. The logic is like this:

验证:DefaultAuthenticateScheme或DefaultScheme
挑战:DefaultChallengeScheme或DefaultScheme
禁止:DefaultForbidScheme，DefaultChallengeScheme或DefaultScheme
登录:DefaultSignInScheme或DefaultScheme
退出:DefaultSignOutScheme或DefaultScheme

Authenticate: DefaultAuthenticateScheme, or DefaultScheme
Challenge: DefaultChallengeScheme, or DefaultScheme
Forbid: DefaultForbidScheme, or DefaultChallengeScheme, or DefaultScheme
Sign-in: DefaultSignInScheme, or DefaultScheme
Sign-out: DefaultSignOutScheme, or DefaultScheme

如您所见，如果未配置特定的默认操作，则每个身份验证操作都将退回到DefaultScheme.因此，通常会看到正在配置DefaultScheme，然后为需要其他方案的用户配置了特定的操作.

As you can see, each of the authentication actions falls back to DefaultScheme if the specific action’s default isn’t configured. So what you will typically see is the DefaultScheme being configured, and then the specific actions are configured for those where a different scheme is required.

您的示例很好地说明了这一点:使用OIDC，您将需要一种登录方案，该方案可以保留外部身份验证提供程序提供的身份.因此，您通常会看到OIDC和Cookie身份验证方案:

Your example shows this pretty well: With OIDC, you will need a sign-in scheme that can persist the identity that is provided by the external authentication provider. So you will usually see the OIDC and cookie authentication schemes:

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

对于用户来说，正常的交互是通过cookie身份验证方案进行的:当他们访问Web应用程序时，cookie身份验证方案将尝试使用其cookie对它们进行身份验证.因此，将cookie身份验证方案用作所有操作的默认方案.

For the user, the normal interaction is through the cookie authentication scheme: When they access the web application, the cookie authentication scheme will attempt to authenticate them using their cookie. So using the cookie authentication scheme as the default scheme for all operations.

例外是在挑战身份验证时:在这种情况下，我们希望将用户重定向到OIDC提供程序，以便他们可以在那里登录并以身份返回.因此，我们将默认的挑战方案设置为OIDC方案.

The exception is when challenging the authentication: In that case, we want the user to be redirected to the OIDC provider, so they can log in there and return with an identity. So we set the default challenge scheme to the OIDC scheme.

此外，我们还将OIDC方案与cookie方案链接在一起.当用户受到挑战并使用其外部身份验证提供程序登录时，他们将使用其外部身份发送回Web应用程序.尽管OIDC方案无法持久保留该身份，所以它使用签名不同的方案-cookie方案，然后它将代表OIDC方案持久化身份.这样，cookie方案将为OIDC身份创建一个cookie，并且在下一个请求时，cookie方案(这是默认方案)将能够使用该cookie再次对用户进行身份验证.

In addition, we also link the OIDC scheme with the cookie scheme. When the user gets challenged and logs in with their external authentication provider, they will get sent back to the web application with their external identity. The OIDC scheme cannot persist that identity though, so it signs in using a different scheme—the cookie scheme—which will then persist the identity on behalf of the OIDC scheme. Soo the cookie scheme will create a cookie for the OIDC identity, and on the next request, the cookie scheme (which is the default scheme) will be able to authenticate the user again using that cookie.

因此，在大多数情况下，只需指定默认方案即可，然后根据您的身份验证设置，可以更改一个或两个显式操作.但是从理论上讲，您可以完全设置一个非常复杂的设置，包括不同的默认值和多种方案:该框架为您提供了很大的灵活性.

So most of the time, you will be fine with just specifying the default scheme and then depending on your authentication setup maybe change one or two explicit actions. But theoretically, you can totally set up a very complex setup of different defaults and multiple schemes: The framework gives you a lot of flexibility here.

这篇关于在ASP.NET Core上配置DefaultScheme和DefaultChallengeScheme有什么意义?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

Bearer