Spring Security ReactiveRemoteJWKSource to respect http.proxy system properties

Expected Behavior

It would be great for ReactiveRemoteJWKSource to use a WebClient instance that respects the http.proxy system properties, as described in https://github.com/reactor/reactor-netty/issues/887 .

Current Behavior

ReactiveRemoteJWKSource creates a WebClient instance that ignores the http.proxy properties.

Context

We have a resource server application built with spring webflux. Our oAuth2 server is accessible only through a proxy . Our application is unable to reach the oauth2 server in order to validate tokens because requests to the oAuth2 server from our spring reactive application are not routed through the proxy.

I haven't managed to find a workaround yet, any suggestions welcome!

Comment From: jzheaux

Have you already tried:

@Bean 
public ReactiveJwtDecoder jwtDecoder() {
    WebClient web = // ... configure your own
    return NimbusReactiveJwtDecoder.withJwkSetUri(uri).webClient(web).build();
}

As far as how to change ReactiveRemoteJWKSource, do you have a suggestion for how it should be constructing WebClient differently?

Comment From: alampada

Thank you @jzheaux , that worked great! Much appreciated.

In terms of constructing the WebClient differently, my suggestion would be something like:

WebClient.builder()
            .clientConnector(new ReactorClientHttpConnector(HttpClient.create().proxyWithSystemProperties())).build()

I noticed that we didn't have to define a bean in our spring MVC-based services in order to use the proxy. I suspect that the reactive implementations do not take the system properties into account, while the MVC ones do so. Ultimately, it might be RestTemplate and WebClient behaving differently?

Comment From: jzheaux

Thanks for the info, @alampada.

I suspect that the reactive implementations do not take the system properties into account, while the MVC ones do so.

That sounds a bit more like a question for the Spring Framework folks.

For now, I think let's leave Spring Security as-is since it's straightforward to configure a WebClient to your needs. If this usage becomes quite common, we can take another look.

Comment From: saurabhgour

We have a requirement where we configure our Spring Boot JVM to use fiddler during our local development. If we build the WebClient object like suggested by @alampada everywhere in the spring code, it would make the proxy configuration very easy without a need to explicitly override any beans.

WebClient.builder()
            .clientConnector(new ReactorClientHttpConnector(HttpClient.create().proxyWithSystemProperties())).build()

I am looking at one case under AbstractWebClientReactiveOAuth2AccessTokenResponseClient class where WebClient is built as follows.

private WebClient webClient = WebClient.builder().build();

So we'd have to understand the specific bean and override WebClient here as well as every other place where Spring uses a WebClient builder without proxy configuration which becomes cumbersome to debug. Is there a possibility to make the WebClient instances defined in Spring classes with a proxy, it could optionally be enabled/disable through a spring property in application.yml

Comment From: jzheaux

@saurabhgour, please see https://github.com/spring-projects/spring-security/issues/8882