authentication
authorization
DefaultChallengeScheme
security
ASP.NET Core

No authenticationScheme was specified, and there was no DefaultChallengeScheme found with default authentification and custom authorization

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

This ASP.NET Core error appears when authorization decides a request needs to be challenged, but the application has not told the framework which authentication scheme should handle that challenge. In practice, the protected endpoint is configured, yet the runtime does not know whether it should redirect to a login page, emit a bearer challenge, or do something else.

Understand What The Challenge Scheme Does

ASP.NET Core authentication has more than one default. The two most relevant here are:

  • 'DefaultAuthenticateScheme, which tells the framework how to read the current user from the request'
  • 'DefaultChallengeScheme, which tells the framework what to do when an unauthenticated user hits a protected resource'

If a custom policy or authorization attribute runs and no challenge scheme is configured, the runtime throws the error in the title. That is why the failure often shows up during authorization even though the real fix belongs in the authentication setup.

Configure Authentication With Explicit Defaults

The usual fix is to register authentication and set a default scheme that matches the handler you actually use.

For cookie authentication:

csharp
1using Microsoft.AspNetCore.Authentication.Cookies;
2
3builder.Services
4    .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
5    .AddCookie(options =>
6    {
7        options.LoginPath = "/account/login";
8        options.AccessDeniedPath = "/account/denied";
9    });
10
11builder.Services.AddAuthorization();

For JWT bearer authentication:

csharp
1using Microsoft.AspNetCore.Authentication.JwtBearer;
2
3builder.Services
4    .AddAuthentication(options =>
5    {
6        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
7        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
8    })
9    .AddJwtBearer(options =>
10    {
11        options.Authority = "https://issuer.example.com";
12        options.Audience = "api";
13    });
14
15builder.Services.AddAuthorization();

Once those defaults exist, ASP.NET Core knows both how to read credentials and how to challenge when authorization fails.

Keep Middleware Order Correct

Correct service registration is not enough if the middleware pipeline is in the wrong order. Authentication must run before authorization:

csharp
1var app = builder.Build();
2
3app.UseRouting();
4app.UseAuthentication();
5app.UseAuthorization();
6
7app.MapControllers();
8app.Run();

If UseAuthorization() runs first, the user principal may never be populated correctly and the resulting error messages can be misleading.

Be Explicit In Multi-Scheme Applications

The error becomes more common when an app uses multiple schemes, such as cookies for browser pages and bearer tokens for APIs. In that setup, a policy or endpoint may need to specify the intended scheme explicitly.

csharp
1builder.Services.AddAuthorization(options =>
2{
3    options.AddPolicy("ApiOnly", policy =>
4    {
5        policy.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);
6        policy.RequireAuthenticatedUser();
7    });
8});

You can also specify the scheme directly on an attribute:

csharp
1[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
2public class ReportsController : ControllerBase
3{
4}

That keeps an API endpoint from accidentally using cookie challenge behavior, or a web page from trying to emit a bearer token challenge.

Debug The Effective Configuration, Not Just The Policy

When the error persists, inspect the effective application setup:

  1. confirm which schemes were registered
  2. confirm whether a default authenticate scheme exists
  3. confirm whether a default challenge scheme exists
  4. confirm middleware order
  5. confirm whether the endpoint or policy expects a specific scheme

This is often faster than staring at a custom authorization handler and guessing. In many cases the handler is fine and the runtime simply has no registered challenge target.

Common Pitfalls

  • Registering authorization policies without a matching authentication scheme.
  • Setting an authenticate scheme but forgetting the challenge scheme in a multi-scheme app.
  • Calling UseAuthorization() before UseAuthentication().
  • Mixing cookies and bearer tokens without telling the protected endpoint which one it should use.
  • Debugging only the custom authorization code while the real problem is missing authentication configuration.

Summary

  • The error means ASP.NET Core needed to challenge the request but had no scheme configured for that step.
  • Fix it by registering authentication with explicit defaults and the correct handler.
  • Keep middleware order as authentication first, authorization second.
  • In multi-scheme apps, tie policies and endpoints to the intended authentication scheme.

Course illustration
Course illustration

All Rights Reserved.