allow assertion to check for kid to be present

[julianhille]

Preflight checklist

• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines."
• I have discussed this feature request with the community.

Describe the background of your feature request

We use some authentication provider like auth0, okta (you name it) to validate our developers to be able to request specific environments and services secured by heimdall in front.

Heimdall internally queries (implicit) these services and we hit rate limits on those auth providers because the jwt token did not have a kid implemented and so caches are not used.

Describe your idea

I really would love the idea of having an assertion that the kid in the jwt must be present for the auth provider to be queried.
That would explicitly fail if kid is not there and would allow to use cached results for kid's.

Are there any workarounds or alternatives?

Yeah there are other options.

• of course make sure all code implements a kid but if it is forgotten we hit rate limits and all apis go down
• implement another level of cache in between heimdall and auth provider (caching is hard...)

Version

0.17.9

Additional Context

No response

[dadrus]

Have you already tried enabling HTTP caching for the JWKS endpoint?

When configuring the jwks_endpoint for the jwt authenticator, you can enable HTTP caching (according to RFC 9111, formerly RFC 7234). In that case, heimdall will cache the JWKS response and avoid fetching it again until it becomes stale, extracting the key from the cached object instead.

Here’s an example snippet:

mechanisms:
  authenticators:
    - id: jwt_authenticator
      type: jwt
      config:
        jwks_endpoint:
          url: https://example.com/jwks
          method: GET
          http_cache: # <- configure HTTP caching
            enabled: true # <- enable it
            default_ttl: 5m
        # other jwt authenticator related properties

Even if the response from the JWKS endpoint does not contain any HTTP cache headers (e.g. Cache-Control or Expires), it is cacheable (a 200 OK response to a GET request). In that case, default_ttl defines how long the response is considered fresh.

If the response contains an Expires header with a future timestamp (or an appropriate Cache-Control header), heimdall will cache the response according to those header settings. If the resulting freshness lifetime exceeds default_ttl, the effective lifetime is capped accordingly.

In all cases, heimdall will reuse the cached response for subsequent requests until it becomes stale.

[dadrus]

Btw., you can configure http_cache for metadata_endpoint and resolved_endpoints as well.

[dadrus]

@julianhille: Have you tried the approach, I described above? Did it work for you?

[julianhille]

I see where you are coming from and I will do that. But I would still like to directly reject if there is no kid given for that authenticator.

[dadrus]

I understand the need for this functionality, and I’ve received other requests in the past from community members to extend the functionality around authentication data assertions. However, the current approach is not flexible enough to accommodate such requests without introducing breaking changes, either now or in the future. Therefore, I suggest starting a discussion on Discord to come up with a solid overall design first. I’d appreciate it if you could start a topic in the #ideas channel for that.