Expected Behavior

The ReactiveOidcIdTokenDecoderFactory should be able to use a custom Webclient if the token is decoced via jwkSetUri.

Expected sourcecode:

NimbusReactiveJwtDecoder.withJwkSetUri(jwkSetUri).jwsAlgorithm((SignatureAlgorithm) jwsAlgorithm).webClient(this.webclient).build()

Current Behavior

Currently the ReactiveOidcIdTokenDecoderFactory is not using a dedicated webclient at all. Therefore the JwkSetUriReactiveJwtDecoderBuilder used for creating the NimbusReactiveJwtDecoder is using a Webclient created via WebClient.create()

Context

This is an Issue for people trying to use OIDC/OAuth behind corporate proxys. Currently in the complete Spring-OAuth-Client-Package it is not possible to set a custom Webclient globally. Instead it is necessary to provide a Webclient for every single component involved. See https://github.com/spring-projects/spring-security/issues/8882#user-content-oauth2-client for detailed informations.

My current Solution is to completely copy ReactiveOidcIdTokenDecoderFactory and provide a CustomReactiveOidcIdTokenDecoderFactory class just to be able to set a Webclient, which feels a bit hacky. Nearly every other component allows to set the Webclient with a setter.

I will go ahead and work on a pullrequest for this enhancment.

Comment From: jzheaux

Thanks for the suggestion, @stephanabel.

I wonder if it's better to introduce Function<ClientRegistration, ReactiveJwtDecoder>, potentially deprecating the other factory methods. My concern with adding Function<ClientRegistration, WebClient> is the amount of the NimbusJwtDecoder builder API that is now being replicated here.

Function<ClientRegistration, ReactiveJwtDecoder> gives the application full access to the NimbusJwtDecoder API (like jwtProcessorCustomizer and cache) without leaking more of the NimbusJwtDecoder API into this factory class.

That said, I'm not as familiar with this class as Joe is. What should be done here, @jgrandja?

Comment From: stephanabel

Hi, thanks for looking into this. Looking at https://github.com/spring-projects/spring-security/issues/10604 gets me thinking that it would have made sense to look for similar requests in a non reactive context. https://github.com/spring-projects/spring-security/pull/10513#issuecomment-972979280 describes the same request for non reactive.

@jgrandja commented on this:

It doesn't make sense from a design standpoint to expose OidcIdTokenDecoderFactory.setRestOperations(), since not all JwtDecoder's would require a RestOperations.

This also applies here. So i am closing this issue.