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:
For JWT bearer authentication:
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:
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.
You can also specify the scheme directly on an attribute:
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:
- confirm which schemes were registered
- confirm whether a default authenticate scheme exists
- confirm whether a default challenge scheme exists
- confirm middleware order
- 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()beforeUseAuthentication(). - 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.

