Custom JWKS Uri resolution function for WithIssuersResolver

[springroll12]

Checklist

• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

With a dynamic issuer configuration via validator.WithIssuerResolver it does not seem possible to specify a non-standard JWKS endpoint for each issuer. What would be handy is a similar function validator.WithJWKSResolver or an additional return value to WithIssuerResolver that sets the custom JWKS endpoint rather than relying on discovery.

In our case we need the dynamic nature of MultiIssuerProvider and WithIssuerResolver, but also need to set custom JWKS endpoints per issuer. These endpoints follow a simple pattern, but there doesn't appear to be an interface to set this. With static issuers this is possible, but unless I'm mistaken it is not with the new MCD implementation. My primary use case is to exchange the full external issuer domain for an internal domain (e.g. Kubernetes service domain). This is particularly useful when testing on localhost.

Describe the ideal solution

WithIssuerResolver allows configuring more details tied to the issuer. E.g. JWKS uri, or strict hostname matching and so forth.

Alternatives and current workarounds

• Set static issuers and be unable to customize per tenant.
• Create custom provider?

Additional context

Really love the new MCD implementation! Very clean implementation!

[developerkunal]

Hi @springroll12,

I hope you're doing well! Sorry for the late response on this.

Thanks for the feature request, and really glad you're enjoying the MCD implementation!

We've thought about this quite a bit and unfortunately we won't be able to add a JWKS URI resolver to MultiIssuerProvider. OIDC discovery is a core security boundary for us. When we fetch .well-known/openid-configuration from the issuer, we get double-validation: the metadata's issuer field must match the token's iss claim, and the jwks_uri comes from a source the issuer controls. Any option that lets user code determine the JWKS endpoint directly would bypass that entire chain, and we want to stay strict by default here.

That said, your use case is totally valid. As a workaround, you should be able to use WithMultiIssuerHTTPClient with a custom http.Transport that rewrites the destination host at the network level. That way the logical URIs stay the same (origin validation, double-validation, strict JWKS URI origin all pass), but the actual connection goes to your internal service. Full discovery still runs and all security checks are preserved.

I'm also going to check with the team on whether there's something else we can offer here without compromising the security model. Will follow up if anything comes out of that.

Let me know if you have any questions!