Use multiple JWT Bearer Authentication

Question

Is it possible to support multiple JWT Token issuers in ASP.NET Core 2? I want to provide an API for external service and I need to use two sources of JWT tokens - Firebase and custom JWT token issuers. In ASP.NET core I can set the JWT authentication for Bearer auth scheme, but only for one Authority:

  services
        .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(options =>
        {
            options.Authority = "https://securetoken.google.com/my-firebase-project"
            options.TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateIssuer = true,
                    ValidIssuer = "my-firebase-project"
                    ValidateAudience = true,
                    ValidAudience = "my-firebase-project"
                    ValidateLifetime = true
                };
        }

I can have multiple issuers and audiences, but I can't set several Authorities.

Solution 1

You can totally achieve what you want:

services
    .AddAuthentication()
    .AddJwtBearer("Firebase", options =>
    {
        options.Authority = "https://securetoken.google.com/my-firebase-project"
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "my-firebase-project"
            ValidateAudience = true,
            ValidAudience = "my-firebase-project"
            ValidateLifetime = true
        };
    })
    .AddJwtBearer("Custom", options =>
    {
        // Configuration for your custom
        // JWT tokens here
    });

services
    .AddAuthorization(options =>
    {
        options.DefaultPolicy = new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .AddAuthenticationSchemes("Firebase", "Custom")
            .Build();
    });

Let's go through the differences between your code and that one.

AddAuthentication has no parameter

If you set a default authentication scheme, then on every single request the authentication middleware will try to run the authentication handler associated with the default authentication scheme. Since we now have two possible authentication schemes, there's no point in running one of them.

Use another overload of AddJwtBearer

Every single AddXXX method to add an authentication has several overloads:

• One where the default authentication scheme associated with the authentication method is used, as you can see here for cookies authentication
• One where you pass, in addition to the configuration of the options, the name of the authentication scheme, as on this overload

Now, because you use the same authentication method twice but authentication schemes must be unique, you need to use the second overload.

Update the default policy

Since the requests won't be authenticated automatically anymore, putting [Authorize] attributes on some actions will result in the requests being rejected and an HTTP 401 will be issued.

Since that's not what we want because we want to give the authentication handlers a chance to authenticate the request, we change the default policy of the authorization system by indicating both the Firebase and Custom authentication schemes should be tried to authenticate the request.

That doesn't prevent you from being more restrictive on some actions; the [Authorize] attribute has an AuthenticationSchemes property that allows you to override which authentication schemes are valid.

If you have more complex scenarios, you can make use of policy-based authorization. I find the official documentation is great.

Let's imagine some actions are only available to JWT tokens issued by Firebase and must have a claim with a specific value; you could do it this way:

// Authentication code omitted for brevity

services
    .AddAuthorization(options =>
    {
        options.DefaultPolicy = new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .AddAuthenticationSchemes("Firebase", "Custom")
            .Build();

        options.AddPolicy("FirebaseAdministrators", new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .AddAuthenticationSchemes("Firebase")
            .RequireClaim("role", "admin")
            .Build());
    });

You could then use [Authorize(Policy = "FirebaseAdministrators")] on some actions.

A final point to note: If you are catching AuthenticationFailed events and using anything but the first AddJwtBearer policy, you may see IDX10501: Signature validation failed. Unable to match key... This is caused by the system checking each AddJwtBearer in turn until it gets a match. The error can usually be ignored.

Solution 2

This is an extension of Mickaël Derriey's answer.

Our app has a custom authorization requirement that we resolve from an internal source. We were using Auth0 but are switching to Microsoft Account authentication using OpenID. Here is the slightly edited code from our ASP.Net Core 2.1 Startup. For future readers, this works as of this writing for the versions specified. The caller uses the id_token from OpenID on incoming requests passed as a Bearer token. Hope it helps someone else trying to do an identity authority conversion as much as this question and answer helped me.

const string Auth0 = nameof(Auth0);
const string MsaOpenId = nameof(MsaOpenId);

string domain = "https://myAuth0App.auth0.com/";
services.AddAuthentication()
        .AddJwtBearer(Auth0, options =>
            {
                options.Authority = domain;
                options.Audience = "https://myAuth0Audience.com";
            })
        .AddJwtBearer(MsaOpenId, options =>
            {
                options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters
                {
                    ValidateAudience = true,
                    ValidAudience = "00000000-0000-0000-0000-000000000000",

                    ValidateIssuer = true,
                    ValidIssuer = "https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0",

                    ValidateIssuerSigningKey = true,
                    RequireExpirationTime = true,
                    ValidateLifetime = true,
                    RequireSignedTokens = true,
                    ClockSkew = TimeSpan.FromMinutes(10),
                };
                options.MetadataAddress = "https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0/.well-known/openid-configuration";
            }
        );

services.AddAuthorization(options =>
{
    options.DefaultPolicy = new AuthorizationPolicyBuilder()
        .RequireAuthenticatedUser()
        .AddAuthenticationSchemes( Auth0, MsaOpenId )
        .Build();

    var approvedPolicyBuilder =  new AuthorizationPolicyBuilder()
           .RequireAuthenticatedUser()
           .AddAuthenticationSchemes(Auth0, MsaOpenId)
           ;

    approvedPolicyBuilder.Requirements.Add(new HasApprovedRequirement(domain));

    options.AddPolicy("approved", approvedPolicyBuilder.Build());
});

Solution 3

The solution to your question, is available in following blog post https://oliviervaillancourt.com/posts/Fixing-IDX10501-MultipleAuthScheme

Basically the solutions exists of overriding the regular JWTBearer handler with you own generic handler that can check through the JWTBearerConfig if the issuer in the cfg is the same to the isseur in your token.

The blog post suggests to use seperate handlers for each scheme, that doesn't seem to be needed, a generic class JWTAuthenticationHandler that overrides the HandleAuthenticateAsync method seems to suffice!

Code wise you could implement your startup like this:

 //Using multiple schemes can cause issues when validating the issuesSigningKey therefore we need to implement seperate handlers for each scheme! => cfr: https://oliviervaillancourt.com/posts/Fixing-IDX10501-MultipleAuthScheme
        services.TryAddEnumerable(ServiceDescriptor.Singleton<IPostConfigureOptions<JwtBearerOptions>, JwtBearerPostConfigureOptions>());
        services.AddAuthentication()
        //Set the authenticationScheme by using the identityServer helper methods (we are using a Bearer token)
        .AddScheme<JwtBearerOptions, JWTAuthenticationHandler>(IdentityServerAuthenticationDefaults.AuthenticationScheme, options =>
        {
            //TO DO Get the origin url's from configuration file, instead of setting all url's here 
            options.Authority = _identityServerSettings.Authority;
            options.Audience = _identityServerSettings.Audience;

            options.Events = new JwtBearerEvents
            {
                OnChallenge = context =>
                {
                    return Task.CompletedTask;
                },
                //When using multiple JwtBearer schemes we can run into "OnAuthenticationFailed" for instance when logging in via IdentityServer the AuthenticationHandler will still check in these events, this can be ignored...
                //Cfr => https://stackoverflow.com/questions/49694383/use-multiple-jwt-bearer-authentication
                //If you are catching AuthenticationFailed events and using anything but the first AddJwtBearer policy, you may see IDX10501: Signature validation failed.Unable to match key... This is caused by the system checking each AddJwtBearer in turn until it gets a match. The error can usually be ignored.
                //We managed to fix this issue by adding seperate AuthenticationHandlers for each type of bearer token... cfr: https://oliviervaillancourt.com/posts/Fixing-IDX10501-MultipleAuthScheme
                OnAuthenticationFailed = context =>
                {
                    return Task.CompletedTask;
                },
                OnMessageReceived = context =>
                {
                    return Task.CompletedTask;
                },
                OnForbidden = context =>
                {
                    return Task.CompletedTask;
                },
                OnTokenValidated = context =>
                {
                    return Task.CompletedTask;
                }

            };
        })
        //Set the authentication scheme for the AzureAd integration (we are using a bearer token)
        .AddScheme<JwtBearerOptions, JWTAuthenticationHandler>("AzureAD", "AzureAD", options =>
         {
            options.Audience = _azureAdSettings.Audience;   //ClientId 
            options.Authority = _azureAdSettings.Authority; //"https://login.microsoftonline.com/{tenantId}/v2.0/"

            options.TokenValidationParameters = new TokenValidationParameters
             {
                //Set built in claimTypes => Role
                RoleClaimType = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
             };

             options.Events = new JwtBearerEvents
             {
                 OnChallenge = context =>
                 {
                     return Task.CompletedTask;
                 },
                 //When using multiple JwtBearer schemes we can run into "OnAuthenticationFailed" for instance when logging in via IdentityServer the AuthenticationHandler will still check in these events, this can be ignored...
                 //Cfr => https://stackoverflow.com/questions/49694383/use-multiple-jwt-bearer-authentication
                 //A final point to note: If you are catching AuthenticationFailed events and using anything but the first AddJwtBearer policy, you may see IDX10501: Signature validation failed.Unable to match key... This is caused by the system checking each AddJwtBearer in turn until it gets a match. The error can usually be ignored.
                 //We managed to fix this issue by adding seperate AuthenticationHandlers for each type of bearer token... cfr: https://oliviervaillancourt.com/posts/Fixing-IDX10501-MultipleAuthScheme
                 OnAuthenticationFailed = context =>
                 {
                     return Task.CompletedTask;
                 },
                 OnMessageReceived = context =>
                 {
                     return Task.CompletedTask;
                 },
                 OnForbidden = context =>
                 {
                     return Task.CompletedTask;
                 },
                 OnTokenValidated = context =>
                 {
                     return Task.CompletedTask;
                 }
                 
             };
         });
    }

The JWTAuthenticationHandlerClass can look like this

  using Microsoft.AspNetCore.Authentication;
  using Microsoft.AspNetCore.Authentication.JwtBearer;
  using Microsoft.Extensions.Logging;
  using Microsoft.Extensions.Options;
  using System;
  using System.IdentityModel.Tokens.Jwt;
  using System.Text.Encodings.Web;
  using System.Threading.Tasks;

  namespace WebAPI.Auth
  {
    public class JWTAuthenticationHandler: JwtBearerHandler
    {
    public JWTAuthenticationHandler(IOptionsMonitor<JwtBearerOptions> options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock)
        : base(options, logger, encoder, clock)
    { }

    protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        //Fetch OIDC configuration for the IDP we are handling
        var authorityConfig = await this.Options.ConfigurationManager.GetConfigurationAsync(this.Context.RequestAborted);
        //Determine the issuer from the configuration
        var authorityIssuer = authorityConfig.Issuer;

        var jwtToken = this.ReadTokenFromHeader();
        var jwtHandler = new JwtSecurityTokenHandler();

        //Check if we can read the token as a valid JWT, if not let the JwtBearerHandler do it's thing...
        if (jwtHandler.CanReadToken(jwtToken))
        {
            //Read the token and determine if the issuer in config is the same as the one in the token, if this is true we know we want to let the JwtBearerHandler continue, if not we skip and return noResult
            //This way the next IDP configuration will pass here until we find a matching issuer and then we know that is the IDP we are dealing with
            var token = jwtHandler.ReadJwtToken(jwtToken);
            if (string.Equals(token.Issuer, authorityIssuer, StringComparison.OrdinalIgnoreCase))
            {
                return await base.HandleAuthenticateAsync();
            }
            else
            {
                // return NoResult since the issuer in cfg did not match the one in the token, so no need to proceed to tokenValidation
                this.Logger.LogDebug($"Skipping jwt token validation because token issuer was {token.Issuer} but the authority issuer is: {authorityIssuer}");
                return AuthenticateResult.NoResult();
            }
        }

        return await base.HandleAuthenticateAsync();
    }

    //Fetch the bearer token from the authorization header on the request!
    private string ReadTokenFromHeader()
    {
        string token = null;

        string authorization = Request.Headers["Authorization"];

        //If we don't find the authorization header return null
        if (string.IsNullOrEmpty(authorization))
        {
            return null;
        }

        //get the token from the auth header
        if (authorization.StartsWith("Bearer ", StringComparison.OrdinalIgnoreCase))
        {
            token = authorization.Substring("Bearer ".Length).Trim();
        }

        return token;
    }
}

}

Comments

[Rush Frisby]

Does this require that the header value be changed from firebase or custom solution? ie. instead of Authorization : Bearer <token> that the header be Authorization : Firebase <token> for example? When tried this solution I got the error: "No authentication handler is registered for the scheme 'Bearer'."

[Mickaël Derriey]

No, the headers don't need to change. The error message suggests that you're referring to a non-existent authentication scheme (Bearer). In our examples, the two registered schemes are Firebase and Custom, which are the first arguments of the .AddJwtBearer method calls.

[Rush Frisby]

It was because someone had put [Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)] on the controller methods. This works after I changed it to just be [Authorize]

[terjetyl]

Hi. Was looking for just this solution. Unfortunately I am getting a "No authenticationScheme was specified, and there was no DefaultChallengeScheme found" exception. options.DefaultPolicy is set ok. Any ideas?

[Aron]

This was a supremely helpful answer, and put together a lot of what I've seen in pieces all over the place.

[No Refunds No Returns]

I too found this answer SUPER USEFUL. If I could vote for most supreme answer I've seen in a while, it would be this one. I have it working but have to clean up the code. I had a few extra bits that might be useful for other readers so will leave it as an additional answer. In ASP.Net Core 3.1 you get a few nasty grams that clutter up the log but after reading them, you can see they make sense and are nothing to really worry about. stackoverflow.com/questions/58856735/… has the nasty-grams I'm seeing.

[Pieter]

I get the following error in core 3.1 "No authenticationScheme was specified, and there was no DefaultAuthenticateScheme found". If i understand correctly you dont want to specify a default schema. How to solve this

[Mickaël Derriey]

@Pieter my best guess is that either the [Authorize] attribute or the authorisation policy doesn't explicitly specify the authentication schemes to use for the authentication.

[Pieter]

In core 3.1 .AddAuthentication() need to have an default scheme. auth.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; auth.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme; auth.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme; And btw, the order in de AddAuthorization does matter if i am correct

[Mickaël Derriey]

@Pieter that's not correct, default schemes are not required, as pointed out by my answer. Your schemes also indicate that your setup is in no way related to the question. Please ask a new question if needed.

[Mickaël Derriey]

The authorization policy dictates which authentication schemes are being "tried". Taking the last code sample above, an empty [Authorize] attribute would use the default policy, hence would try both schemes, whereas [Authorize(Policy = "FirebaseAdministrators")] would only try the Firebase scheme. No policy at the action, controller or global level means the endpoint is accessible to anonymous requests, so no scheme would be tried.

[TylerOhlsen]

In core 3.1, the DefaultPolicy is only used when each endpoint type in your Startup UseEndpoints sets RequireAuthorization(). (e.g. .UseEndpoints(rb => rb.MapControllers().RequireAuthorization()))

[Mickaël Derriey]

@TylerOhlsen that's not correct; while it will be used in the case you describe, it's not the only one. It will also be used if you don't specify an authorization requirement at the endpoint level, but decorate MVC controllers and/or actions with an empty [Authorize] attribute.

[mac]

gist.github.com/mac2000/ff95fc54bdc684646bb1de24ef07b333 just in case anyone will need some self contained example, approach is working also there is almost same in docs - docs.microsoft.com/en-us/aspnet/core/security/authorization/‌​…

[Sam]

The experience I am getting is both scheme configurations are being checked and any one failing brings the whole request down. The first one matches the supplied token and I can see OnTokenValidated is executed. Then for some dumb reason it proceeds to validate again using the second scheme which of course fails and a 401 is created. No idea what scenario this is intended to support. Who issues token that support multiple schemes??!

[Mickaël Derriey]

@Sam I created a brand new projet following the concepts of my response and I can't reproduce what you're experiencing. Yes, both schemes are checked, which is expeted, but because one of them succeeds, the overall authorization is considered successful. See gist.github.com/mderriey/994d72a81f9f4324b32e68fec0705a2e for the simplest example I could come up with.

[Jano du Toit]

@MickaëlDerriey We are doing something similar to the above. It seems to work for authentication, but we end up with a scenario where the ClaimsPrincipal is either incorrectly set, or the claims and identities on the ClaimsPrincipal aren't set. Any ideas why this would be?

[Kumar Garapati]

this answer definitely put me in the correct direction but I couldn't get it to work then I followed this article. setting default worked docs.microsoft.com/en-us/aspnet/core/security/authorization/‌​…

[Pedro Costa]

FYI, you may need a custom middleware to populate context.User, see github.com/aspnet/Security/issues/1708#issuecomment-37656749‌​1

[Jossean Yamil]

How can you tell which scheme created the HttpContext.User Property?

[Mickaël Derriey]

@JosseanYamil If both schemes run on the same request, it's possible that HttpContext.User contains 2 identities, one for each scheme. You can set options.TokenValidationParameters.AuthenticationType which will flow to ClaimsIdentity.AuthenticationType, which then allows you to know which identity comes from which scheme.

[Jossean Yamil]

Understood, I see now the AuthenticationType field. Thanks for all the assistance, you have no idea the amount of help you have provided me @MickaëlDerriey

[Mickaël Derriey]

Thanks for the kind words, they're much appreciated 🙇‍♂️

[Jacek Labuda]

Tip: Using two schemas, we can decide which one should be applied on controllers using [Authorize(AuthenticationSchemes = "Firebase")]

[Dekim]

Any hint on how to get the "Authenticated Schema" in a custom AuthorizationHandler ?

[Mickaël Derriey]

@Dekim I think there's no way to access it by default. I'd also suggest there might be a design problem if you need it. In my opinion, a requirement should be handled the same whether it's for the authN scheme A or B. If you do really need it, a potential solution would be to pass it through the authZ requirement, then you could access it in the authZ handler.