Identityserver4: HTTP 500 "No authentication handler is configured to handle the scheme: Automatic" instead of expected 401

[paulczy]

Using the IdentityServer4 Samples "MVC and API" solution I've discovered that I am getting two different behaviors if the app is hosted under IIS Express or not.

When the sample Api app is launched in VS using the "IIS Express" command, making an anonymous request to a secure endpoint I get the expected 401 response.

When launched under the "Api" command using VS I get a 500 response and the following error and stack trace.

System.InvalidOperationException: No authentication handler is configured to handle the scheme: Automatic

dbug: Microsoft.AspNetCore.Hosting.Internal.WebHost[3]
Hosting starting
dbug: Microsoft.AspNetCore.Hosting.Internal.WebHost[4]
Hosting started
Hosting environment: Development
Content root path: C:\Projects\IdentityServer4.Samples-dev\MVC and API\src\Api
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
dbug: Microsoft.AspNetCore.Server.Kestrel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60[1]
Connection id "0HKSHFAGOAFUR" started.
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
Request starting HTTP/1.1 GET http://localhost:5000/
dbug: Microsoft.AspNetCore.Builder.RouterMiddleware[1]
Request did not match any routes.
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
Request finished in 213.5438ms 404
dbug: Microsoft.AspNetCore.Server.Kestrel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60[9]
Connection id "0HKSHFAGOAFUR" completed keep alive response.
dbug: Microsoft.AspNetCore.Server.Kestrel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60[1]
Connection id "0HKSHFAGOAFUS" started.
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
Request starting HTTP/1.1 GET http://localhost:5000/claims
dbug: Microsoft.AspNetCore.Routing.Tree.TreeRouter[1]
Request successfully matched the route with name '' and template 'Claims'.
dbug: Microsoft.AspNetCore.Mvc.Internal.MvcRouteHandler[1]
Executing action Api.ClaimsController.Get (Api)
warn: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.Authorization.AuthorizeFilter'.
info: Microsoft.AspNetCore.Mvc.ChallengeResult[1]
Executing ChallengeResult with authentication schemes ().
fail: Microsoft.AspNetCore.Server.Kestrel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60[13]
Connection id "0HKSHFAGOAFUS": An unhandled exception was thrown by the application.
System.InvalidOperationException: No authentication handler is configured to handle the scheme: Automatic
at Microsoft.AspNetCore.Http.Authentication.Internal.DefaultAuthenticationManager.d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Mvc.ChallengeResult.d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Mvc.Internal.FilterActionInvoker.d__44.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Mvc.Internal.FilterActionInvoker.d__32.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Mvc.Internal.MvcRouteHandler.d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Builder.RouterMiddleware.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at IdentityModel.AspNetCore.ScopeValidation.ScopeValidationMiddleware.d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware 1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware 1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at IdentityServer4.AccessTokenValidation.IdentityServerAuthenticationMiddleware.d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Hosting.Internal.RequestServicesContainerMiddleware.d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Server.Kestrel.Http.Frame 1.d__2.MoveNext()
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
Request finished in 146.3462ms 200
dbug: Microsoft.AspNetCore.Server.Kestrel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60[9]
Connection id "0HKSHFAGOAFUS" completed keep alive response.

The sample app was cloned from the Git repo today.
https://github.com/IdentityServer/IdentityServer4.Samples/tree/dev/MVC%20and%20API

Is this expected behavior? Thanks... -Paul

[leastprivilege]

updated to the latest access token validation MW.

[iberodev]

I'm also having this issue after following the quick start today after the RC1 has been released.
The steps say to create an API using the AspNet API Template and add the [Authorize] attribute to the controller and expect to get a 401 response.
This is what happens if I am using IIS, but if I am running the API project with Kestrel (e.g: dotnet run), the server starts listening on the configured port but when I trigger the first GET requests I am getting the 500 error with the exception
System.InvalidOperationException: No authentication handler is configured to handle the scheme: Automatic

At this point this should not be even related to IdentityServer4 at all, since I haven't added any IdentityServer middleware, just the default Startup.cs created by the API template:

    public class Startup
    {
        public Startup(IHostingEnvironment env)
        {
            var builder = new ConfigurationBuilder()
                .SetBasePath(env.ContentRootPath)
                .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
                .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
                .AddEnvironmentVariables();
            Configuration = builder.Build();
        }

        public IConfigurationRoot Configuration { get; }

         public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc();
        }

        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            loggerFactory.AddConsole(Configuration.GetSection("Logging"));
            loggerFactory.AddDebug();

            app.UseMvc();
        }
    }

I am aware this has nothing to do with IdentityServer, but since it's a step described at the quickstart guide I am now wondering why is using Kestrel any different than IIS when dealing with the [Authorize] attribute without any middleware in the pipeline at all (other than MVC)?

It can create confusion for beginners following the quick start like myself.

[iberodev]

I have created a question at stackoverflow asking why kestrel and iis handle differently the Authorize attribute in a basic AspNet Core project generated with the default Web Api template

[leastprivilege]

You should really open an issue in aspnet/security on github.

I think this is a bug.

[iberodev]

Thank you. I opened a ticket with them here at aspnet/security

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.