[Announcement] AutomaticChallenge Usage

[Tratcher]

In ASP.NET Core each of the authentication middleware have an option named AutomaticChallenge. This option is used to indicate which middleware will be the default for issuing authentication challenges to un-authenticated users. This automatic challenge can be triggered either by the [Authorize] attribute on a Controller or Action, or by invoking HttpContext.Authentication.ChallengeAsync().

There should only be one component in the pipeline specified as the automatic/default challenge issuer. With the exception of a few compatible authentication types (Basic, Bearer, and NTLM, etc.), having multiple authentication middleware with AutomaticChallenge enabled can cause conflicts resulting in unexpected responses. These conflicts are more likely after changes in 1.1. Due to the number of people impacted by these changes we will temporarily revert them in 1.1.1 and make a more comprehensive design change to address these issues for 2.0.

AutomaticChallenge is enabled by default for:

• JwtBearer
• OpenIdConnect
• Identity
• IdentityServer
• Validation & Introspection
• IISIntegration - The AutomaticChallenge functionality is merged with the AutomaticAuthentication option. In 1.1 this middleware has a built in mitigation to skip an automatic challenge if another component has already accepted that challenge.
• WebListener is missing this flag, automatic challenges are always enabled if any Windows authentication schemes are configured. See WebListener/#284

If you add more than one of the above components in your application, including multiple instances of JwtBearer or OpenIdConnect, AutomaticChallenge must be disabled for all but one.

When the application has multiple authentication middleware and you need the non-default one to issue a challenge then that middleware must be invoked by specifying its AuthenticationScheme. E.g. For an application where Identity has AutomaticChallenge enabled and JwtBearer has AutomaticChallenge disabled, JwtBearer must be invoked by specifying it's AuthenticationScheme. This can be done with [Authorize(ActiveAuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)] or HttpContext.Authentication.ChallengeAsync(JwtBearerDefaults.AuthenticationScheme). The Authorize call can be simplified by defining a policy for JwtBearer so you can say [Authorize("ApiPolicy")]

            services.AddAuthorization(options =>
            {
                options.AddPolicy("ApiPolicy", policy =>
                {
                    policy.AddAuthenticationSchemes(JwtBearerDefaults.AuthenticationScheme);
                    policy.RequireAuthenticatedUser();
                });
            });

The default behavior of [Authorize] can be changed to an AuthorizationPolicie that always specifies an AuthenticationScheme, bypassing AutomaticChallenge settings. HttpContext.Authentication.ChallengeAsync() is not affected by AuthorizationPolicies.

            services.AddAuthorization(options =>
            {
                options.DefaultPolicy = new AuthorizationPolicyBuilder("Identity.Application").RequireAuthenticatedUser().Build();
            });

See IdentityCookieOptions.

This information will also be added to http://docs.asp.net.

[kevinchalet]

Note: you can add the aspnet-contrib validation and introspection middleware to the list, 'cause they also enable automatic challenge by default (https://github.com/aspnet-contrib/AspNet.Security.OAuth.Extensions/blob/dev/src/AspNet.Security.OAuth.Validation/OAuthValidationOptions.cs#L18 / https://github.com/aspnet-contrib/AspNet.Security.OAuth.Extensions/blob/dev/src/AspNet.Security.OAuth.Introspection/OAuthIntrospectionOptions.cs#L20)

[Tratcher]

@PinpointTownes I saw those but wasn't sure if they were just diagnostic tools or something that would be used in a production app?

[kevinchalet]

@Tratcher no no, those are real production middleware:

• The validation middleware is Katana's OAuthBearerAuthenticationMiddleware equivalent in the vNext world (except it uses the ASP.NET Core Data Protection stack). It's primarily meant to be used with ASOS and OpenIddict.

• The introspection middleware implements the OAuth2 introspection specification. It can be used with any server providing an introspection endpoint.

[Tratcher]

@PinpointTownes Updated

[Tratcher]

On a related note: AutomaticAuthenticate Usage

This option serves two purposes:

• It indicates if the middleware should examine each request for credentials as it arrives, process them, and set HttpContext.User.
• It indicates if the middleware should respond to HttpContext.Authentication.AuthenticateAsync(AuthenticationManager.AutomaticScheme).

Missing or invalid credentials will not fail the request or issue a challenge at this stage, that's for Authorization components determine later.

The following middleware have AutomaticAuthenticate enabled by default:

• Cookies
• JwtBearer
• Identity (Cookies)
• IdentityServer
• Validation & Introspection
• IISIntegration - The AutomaticAuthenticate functionality is merged with the AutomaticAuthentication option.
• WebListener is missing this flag, the AutomaticAuthenticate behavior is always enabled if any Windows authentication schemes are configured.

AutomaticAuthenticate does not apply to OAuth, OpenIdConnect, or similar remote auth middleware, they only process requests on their designated CallbackPath's.

If multiple middleware have this option enabled and successfully produce a ClaimsIdentity, those identities will be combine into a single ClaimsPrincipal for HttpContext.User. This may confuse your authorization logic if there are conflicting claims. It is not recommended for clients to send multiple kinds of authentication on a single request, but if they do and you need to avoid conflicts then you can use the same approaches described above for AutomaticChallenge.

AutomaticAuthenticate may also be disabled as a performance optimization if clients send credentials on most requests but only a few of your actions require them. The credentials can be processed on demand by calling AuthenticateAsync, Authorize, or an AuthorizationPolicy with the correct authentication scheme name.

[Eilon]

We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.

[fabricejumarie]

Hello,
I try to use the both authentication scheme JwtBearerDefaults.AuthenticationScheme and Windows authentication. The user log in by calling an authentication controller which required Windows Authentication, the windows user's name is retrieved from http request and validated from database by using Identity framework. If the user is validated, a JWT is generated and send to the client and next I would like that the user navigation use only this JWT to access protected data.

So that IIS accepts incoming HTTP request with JWT , I enable Anonymous authentication in addition to Windows Authentication.

Now I would like to force Windows Authentication on authentication controller and use JWT bearer for all other controllers.

Does anyone can help me for that, I try so many thing but without success?

I commit my code here : https://github.com/fabricejumarie/Authentication_WebApiCore2

[Eilon]

Hi, it looks like you are posting on a closed issue/PR/commit!

We're very likely to lose track of your bug/feedback/question unless you:

1. Open a new issue
2. Explain very clearly what you need help with
3. If you think you have found a bug, include detailed repro steps so that we can investigate the problem.

[Maximys]

Chris, thank you so much for this issue. It help me so much.