Provide Options to JwtBearerAuthenticationScheme dynamically per request

[vpachipenta]

I have a multi-tenant web application. Each tenant has a unique hostname. ex. tenant1.mycompany.com, tenant2.mycompany.com. We have IdentityServer4 based app to issue oAuth 2 tokens. This token issuer app also works in a multi-tenant model i.e. same instance of the application can be reached as https://tenant1.mycompany.com/tokenissuer etc. We have other services in our application, which hosts APIs supporting different functional areas. All these services are multi-tenant applications and accessible as http://tenant1.mycompany.com/service1/api/...

For the other services (developed using ASP.Net Core 3.1) to accept and validate access tokens issues by the token issuer, I am trying to use JwtBearerAuthenticationScheme. However, the configurations (i.e. issues, authority, IssuerSigningKey, etc - JwtBearerOptions) for this scheme need to be provided at the time of configuring services. We will not have these details at the time of application startup, as the configuration values are different for each tenant.

Is there a way to provide these options per request? We have another middleware, which identifies a tenant and builds all necessary configuration at the beginning of the request pipeline. I am currently using the following code snippet in my ConfigureServices method, to test using a hardcoded tenant.

.AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
      {
        options.Authority = "https://tenant1.mycompany.com/tokenissuer";
        options.TokenValidationParameters = new TokenValidationParameters
        {
          ValidAudience = "https://tenant1.mycompany.com/tokenissuer/resources",
          ValidIssuer = "https://tenant1.mycompany.com/tokenissuer",
          ValidateIssuerSigningKey = true,
          IssuerSigningKey = xxxxx ,
          ValidateIssuer = true,
          ValidateAudience = true,
          ValidateLifetime = true,
        };
      });

[Tratcher]

No, multi-tenant auth is not currently supported. The closest you can get today is to add a JwtBearer instance per tenant at startup and then invoke them by auth scheme name.

[vpachipenta]

Thanks for the quick response. I ended up creating a CustomJWTBearerAuthenticationScheme to handle this situation.

Is there a possibility to add a new constructor to AuthenticationHandler in future releases of ASP.Net Core

AuthenticationHandler(TOptions options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock)

That would help solve situations like this using a custom scheme inheriting JwtBearerHandler. Something similar to below:

public class CustomJwtBearerAuthenticationHandler : JwtBearerHandler
  {
    public CustomJwtBearerAuthenticationHandler(IHttpContextAccessor contextAccessor, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock) : base(GetJwtBearerOptions(contextAccessor), logger, encoder, clock)
    {
      
    }

    private static JwtBearerOptions GetJwtBearerOptions(IHttpContextAccessor contextAccessor)
    {
      var currentRequest = contextAccessor.HttpContext.Request;
      return new JwtBearerOptions() { /* code to populate configuraiton values basing on  incoming tenant request */ }
    }
}

[Tratcher]

Is there a possibility to add a new constructor to AuthenticationHandler in future releases of ASP.Net Core

We don't want to add APIs piecemeal that only address narrow parts of the multi-tenant scenario. If we do decide to support mult-tenant as first class or through extensibility we'd want to work out a comprehensive design first.

Have you considered implementing an IAuthenticationSchemeProvider instead? This allows for the dynamic addition and removal of auth schemes and their associated options.

[vpachipenta]

I haven't tried IAuthenticationSchemeProvider option yet. I will verify this option. Thanks for the followup.