Setting DefaultScheme in authentication configuration is not working

[glen-84]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Setting DefaultScheme in authentication configuration does not appear to work.

Expected Behavior

No response

Steps To Reproduce

• Download this directory: https://github.com/dotnet/aspnetcore/tree/main/src/Security/Authentication/JwtBearer/samples/MinimalJwtBearerSample. (I used https://download-directory.github.io/)
• Fix up the MinimalJwtBearerSample.csproj file (set TargetFramework to net7.0, and add a package reference to Microsoft.AspNetCore.Authentication.JwtBearer version 7.0.2).
• Run the project.
• Load http://localhost:5259/protected.
• See exception.

Exceptions (if any)

System.InvalidOperationException: No authenticationScheme was specified, and there was no DefaultChallengeScheme found. The default schemes can be set using either AddAuthentication(string defaultScheme) or AddAuthentication(Action<AuthenticationOptions> configureOptions).
   at Microsoft.AspNetCore.Authentication.AuthenticationService.ChallengeAsync(HttpContext context, String scheme, AuthenticationProperties properties)
   at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.<>c__DisplayClass0_0.<<HandleAsync>g__Handle|0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

.NET Version

7.0.102

Anything else?

No response

[captainsafia]

We removed support for setting the default scheme from configuration in preview7. See #42578. For .NET 7, the default scheme is inferred if there is only one scheme registered on the application. For other scenarios, we wanted to stick with the existing conventions for setting the default scheme.

The fact that it exists in the sample is an artifact of it not being updated in reaction to the change.

[glen-84]

That's a pity. This one, along with being able to set NameClaimType, would allow me to use:

builder.Services
    .AddAuthentication()
    .AddJwtBearer("FusionAuth")
    .AddJwtBearer("UserJwts");

Instead of:

builder.Services
    .AddAuthentication(builder.Configuration.GetRequiredSection("Authentication")
        .GetValue<string>("DefaultScheme")!)
    .AddJwtBearer(
        "FusionAuth",
        options => options.TokenValidationParameters.NameClaimType = "preferred_username")
    .AddJwtBearer("UserJwts");

[davidfowl]

var scheme = builder.Configuration["Authentication:DefaultScheme"] ?? throw new InvalidOperationException("Missing default scheme");
builder.Services
    .AddAuthentication(scheme)
    .AddJwtBearer(
        "FusionAuth",
        options => options.TokenValidationParameters.NameClaimType = "preferred_username")
    .AddJwtBearer("UserJwts");

A little refactoring goes a long way in making the code look more readable.

[glen-84]

Sure. It's still not as clean though. 🙃

[captainsafia]

Another approach is to implement a PostConfigureOptions service that maps the NameClaimType (and any other values you might need) to the options.

[ghost]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.