TokenValidator infers valid issuer from request instead of supporting a set of valid issuers

[dIeGoLi]

Use case

My identity server instance has a configured IssuerUri in the IdentityServerOptions: authority

1. I request an access token using MTLS which leads to an issuer like mtls.authority
2. I send this access token to service1. Service1 wants to exchange this access token (not using an mtls connection) but fails because the issuer is not accepted as valid.

Relevant code parts

When implementing an IExtensionGrantValidator you'll need to validate the incoming token.
var validationResult = await _validator.ValidateAccessTokenAsync(subjectToken);

The default TokenValidator will create TokenValidationParameters on the fly.

var parameters = new TokenValidationParameters
{
    ValidIssuer = await _issuerNameService.GetCurrentAsync(),
    IssuerSigningKeys = validationKeys.Select(k => k.Key),
    ValidateLifetime = validateLifetime,
    ClockSkew = _options.JwtValidationClockSkew
};

As valid issuer is a single value determined through DefaultIssuerNameService.
This name service will take either the IdentityServerOptions.IssuerUri (which i have specified because the service is behind a reverse proxy) or the request.Host (without mtls in case its an mtls connection).

Conclusion

With this default behaviour no access token obtained through mtls or any third party cold be exchanged, without replacing implementation of these mentionend services. Or is there something i am not considering?

I suggest that IdentityServerOptions would have a TokenValidationParameters property like the options when registration authentication schemes. This would give control over, which tokens are accepted to be exchanged.
I would appreciate your opinion or guidance on this.

[wcabus]

Short answer: you'll most likely need to implement some custom logic indeed to set the correct TokenValidationParameters. I don't really see how adding options to IdentityServerOptions would help here, since the TokenValidationParameters may need to change for each request based on the current host's issuer name if detected dynamically, changing validation keys, ...

[wcabus]

I do wonder where the difference in issuer comes from between the value in the access token and the current issuer name, especially if you've configured the issuer statically using the IssuerUri property: the DefaultIssuerNameService will immediately return if the IssuerUri has been configured, regardless of MTLS being used.

I've also checked the following scenario's:

Configuring an MTLS subdomain

If you set options.MutualTls.DomainName = "mtls";, then the issued access token will contain the original host as the iss claim value (e.g. "iss": "https://auth.example.org" (without the mtls subdomain), or will be set to the value of options.IssuerUri if it was statically configured.

Configuring a fully qualified MTLS domain

If you set options.MutualTls.DomainName = "mtls.auth.example.org";, then the issued access token will contain a different issuer claim value depending on whether or not the IssuerUri was statically configured.

1. When options.IssuerUri = "https://auth.example.org";, then the iss claim will be "https://auth.example.org"
2. When options.IssuerUri is not configured, then the iss claim will be "https://mtls.auth.example.org"

[dIeGoLi]

Thank you very much @wcabus for wondering 👍 . I wanted to prove your statement wrong:
"Configuring a fully qualified MTLS domain: 1. When options.IssuerUri = "https://auth.example.org";, then the iss claim will be "https://auth.example.org""

And it made me realize that in my case IssuerUri is not set in the options as expected. By setting it, i have a working use case. Without setting it the problem would still stand. I suggested adding validation param options to IdentityServerOptions because also IssuerUri specified there is taken as ValidIssuer. So why not have a set of valid issuers there or a complete validation param object. I don't think each token exchange request must really have unique validation option, even though possible of course.
But since i have no practical problem anymore with setting IssuerUri these matter is resolved for me 🥇