Support OpenID Connect Discovery in the JWT plugin

[gijs-martens]

Is your feature request related to a problem? Please describe.

The JWT authentication plugin requires a direct url to the JWKS endpoint for each identity provider. This means every provider's JWKS path has to be known upfront and configured explicitly.

The problem is that there is no standardized path for JWKS endpoints. Different providers use different paths:

• /.well-known/jwks.json
• /.well-known/openid-configuration/jwks
• /realms/{realm}/protocol/openid-connect/certs
• /oauth2/v3/certs

This is exactly the problem that OpenID Connect Discovery 1.0 and RFC 8414 (OAuth 2.0 Authorization Server Metadata) solve. The .well-known/openid-configuration endpoint returns a JSON document containing the jwks_uri field, so the consumer never has to know the actual JWKS path.

In our case, we have three identity providers with different JWKS paths. If any of them changes their JWKS path, we have to update our Router configuration and redeploy. With discovery, the Router would resolve the correct URI automatically.

Describe the solution you'd like

Support for OpenID Connect Discovery in the JWT plugin's jwks configuration. Something like:

authentication:
  router:
    jwt:
      jwks:
        - issuer: https://example.com
          discovery: https://example.com/.well-known/openid-configuration
          poll_interval: 1hour

The plugin would fetch the discovery document, read the jwks_uri field, and use that to download the JWKS. The poll_interval would apply to the JWKS itself. The discovery document could be re-fetched on JWKS errors or on a separate (longer) interval.

This would also allow the issuers validation to be derived from the issuer field in the discovery document, rather than configuring it separately. For example:

authentication:
  router:
    jwt:
      jwks:
        - discovery: https://example.com/.well-known/openid-configuration
          poll_interval: 1hour
          discovery_poll_interval: 24hours

Describe alternatives you've considered

Hardcoding the JWKS URLs, which is what we do today. It works, but it couples the Router configuration to each provider's internal URL structure. If a provider changes their JWKS path, we have to update and redeploy.

Building a native Rust plugin that fetches the discovery document and resolves the JWKS URI before passing it to the JWT plugin. However, the native plugins documentation explicitly discourages building custom native plugins and recommends using built-in functionality where possible. Discovery support in the JWT plugin itself would be the right place for this.

Additional context

The OpenID Connect Discovery 1.0 spec defines the jwks_uri field as part of the provider metadata response. It is a required field, so any compliant provider will have it.

RFC 8414 defines the same mechanism for OAuth 2.0 authorization servers that may not implement full OpenID Connect but still expose metadata at .well-known/oauth-authorization-server.

Most other API gateways and token validation libraries support discovery out of the box (e.g. openid-client in Node.js, Spring Security's issuer-uri configuration, express-oauth2-jwt-bearer).