spring-projects
Allow usage of reactive WebClient for NimbusJwtDecoder to retrieve JwkSet
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.
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.
@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.
@jzheaux @jgrandja @sjohnr is this issue up for contribution ? can I work on this ?
@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.
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?
