Expected Behavior

Should it be possible to use reactive WebClient to create non-reactive JwtDecoder?

NimbusJwtDecoder.withJwkSetUri(properties.getJwt().getJwkSetUri())
        .webClient(WebClient.builder().build())
        .cache(jwkSetCache)
        .build()

Current Behavior

It is only possible to use RestTemplate as http client option:

NimbusJwtDecoder.withJwkSetUri(properties.getJwt().getJwkSetUri())
        .restOperations(new RestTemplate())
        .cache(jwkSetCache)
        .build()

Context

A lot of non-reactive applications use reactive WebClient in a non-reactive manner, not having RestOperations bean created for the application, so I think it might have sense to allow usage of WebClient instead.

Comment From: sjohnr

Related #10309 (and possibly #8882)

Comment From: jzheaux

Thanks for the suggestion, @20fps. We try and stay away from introducing mutually-exclusive options in builders, so I'd not recommend making the change in this way.

That said, this seems like a good time to add NimbusJwtDecoder#withJwkSource, which already exists in NimbusReactiveJwtDecoder.

In this way, you could create your own WebClient-based implementation of ResourceRetriever:

@Bean 
JwtDecoder jwtDecoder(WebClient web) {
    JWKSource<SecurityContext> jwkSource = new RemoteJWKSet<>(url, (u) -> {
        String result = web.get().uri(u.toString()) ...
        return new Resource(result, "UTF-8");
    });
    return NimbusJwtDecoder.withJwkSource(jwkSource).build();
}

Are you able to submit a PR that adds NimbusJwtDecoder#withJwkSource? If possible, it would be nice for the other builders to delegate to this more general-purpose one.

Comment From: jgrandja

@jzheaux Before we consider adding NimbusJwtDecoder.withIssuerLocation() and NimbusJwtDecoder.withJwkSource(), we should consider this potential solution as well. Ideally, we introduce only 1 new API rather than 2 or more.

Comment From: Abhijeetmishr

@jzheaux @jgrandja @sjohnr is this issue up for contribution ? can I work on this ?

Comment From: tinolazreg

Any update on this issue?

Comment From: jgrandja

@Abhijeetmishr @tinolazreg We're going to hold off on this issue. I agree with @jzheaux in this comment

We try and stay away from introducing mutually-exclusive options in builders, so I'd not recommend making the change in this way.

With the introduction of the new RestClient in Spring Framework 6.1, we likely will deprecate RestOperations in favour of RestClient at some point. We don't have a timeline for this.

Comment From: lucar94

Hello, I would like to try contributing to this issue. Should we make a backward-compatible change by deprecating the methods that use RestTemplate and creating a new public JwkSetUriJwtDecoderBuilder restClient(RestClient restClient) method? What are your thoughts on it?