Default jwk set fetcher implementation leading to "Request Entity Too Large"

[turneand]

Expected Behavior

When requesting a jwks file we should not be sending excessive headers to the jwks provider, leading to "Request Entity Too Large". Irrespective on whether we're using the ReactorCacheJwkSetFetcher or the CacheableJwkSetFetcher

Actual Behaviour

When upgrading to the latest micronaut version, without defining the jwks cache (basically the default) the ReactorCacheJwkSetFetcher appears to be used. When using this alongside any filter that modifies the request headers (in our instance the filter is provided by opentelemetry) we end up continually appending extra headers to the request and will eventually cause the server hosting the jwks file to reject our requests.

Steps To Reproduce

Fresh application, with a dependency on micronaut-security-jwt.

Create one filter to simply log the headers as the final step:

@Filter(pattern = "/jwks.json")
@Order(Integer.MAX_VALUE)
public class LogHeadersFilter implements HttpClientFilter {
  private final Logger log = LoggerFactory.getLogger(getClass());
  public Publisher<? extends HttpResponse<?>> doFilter(MutableHttpRequest<?> rrequest, ClientFilterChain chain) {
    log.info("request: {}, headers= {}", request.getUri(), request.getHeaders().asMap());
    return chain.proceed(request);
  }
}

and a simple POC to add a header to the request (in our real apps, this is opentelemetry traceparent)

@Filter(pattern = "/jwks.json")
public class AddHeaderFilter implements HttpClientFilter {
  private final Logger log = LoggerFactory.getLogger(getClass());
  public Publisher<? extends HttpResponse<?>> doFilter(MutableHttpRequest<?> rrequest, ClientFilterChain chain) {
    log.info("Add custom header");
    return chain.proceed(request.header("hdr", "a really long string ..."));
  }
}

Running the application with the above, and then hitting an authenticated endpoint, we see in the logs the header "hdr" has multiple copies of the value, and the number of copies increases with each log . Until eventually the server exposing the jwks file returns an error indicating the "Request Entity Too Large", and our service becomes unusable, requiring a restart.

However, if we set the property:

micronaut:
  caches:
    jwks:
      expire-after-write: 60s

then we observe the header only has the one value each time it is logged. The issue here, is that the default behaviour (when blindly upgrading) leads to the exceptions, but requires a new property to be set to avoid this. So although we have a workaround, we have a fair few services that will require updating, and will likely miss this property on one.

Environment Information

No response

Example Application

No response

Version

4.7.1

[thomasmillercf]

We have just hit the same problem in our application, we have had to rollback