Autoconfigured OAuth2 Resource Server is missing client metrics

[mafr]

While using spring-boot-starter-oauth2-resource-server I noticed that there are no HTTP client metrics for any of the calls that are made to the authorization server for downloading public keys.

My configuration:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: http://localhost:8090/realms/myrealm

It looks like the OAuth2ResourceServerJwtConfiguration doesn't set an instrumented RestTemplate, which means the NimbusJwtDecoder and its JwkSetUriJwtDecoderBuilder uses its default uninstrumented instance.

When constructing the JwtDecoder myself using the RestTemplateBuilder provided by Spring Boot, I see client metrics:

    @Bean
    public JwtDecoder jwtDecoder(RestTemplateBuilder builder) {
        RestTemplate rest = builder
                .setConnectTimeout(Duration.ofSeconds(10))
                .setReadTimeout(Duration.ofSeconds(5))
                .build();

        return NimbusJwtDecoder
                .withJwkSetUri(jwkSetUri)
                .restOperations(rest)
                .build();
    }

Example:

http_client_requests_seconds_count{clientName="localhost",method="GET",outcome="SUCCESS",status="200",uri="/realms/myrealm/protocol/openid-connect/certs",} 1.0
http_client_requests_seconds_sum{clientName="localhost",method="GET",outcome="SUCCESS",status="200",uri="/realms/myrealm/protocol/openid-connect/certs",} 0.029850946
http_client_requests_seconds_max{clientName="localhost",method="GET",outcome="SUCCESS",status="200",uri="/realms/myrealm/protocol/openid-connect/certs",} 0.029850946

[wilkinsona]

@mafr Unfortunately, things are a little incomplete in this area in Spring Security. As you have seen, it's possible to customize the RestOperations implementation that's used when creating a decoder from a JWK set URI (NimbusJwtDecoder.withJwkSetUri), but it is not possible to do the same when creating a decoder from an issuer location (JwtDecoders.fromIssuerLocation). spring-projects/spring-security#8882 will hopefully address this and I have just commented on it to bring this latest request to the Security team's attention.

Until things have been addressed in Spring Security, we're limited in what we can do in Spring Boot and we don't want to implement a partial solution that may leave us backed into a corner in the future. Please see #20747 and #20747 for some background on this.

[mafr]

Understood. Thank you for pinging Spring Security on my behalf, much appreciated.