Inspired by #20747, it looks like it would be useful to provide a mechanism for customising the auto-configured NimbusJwtDecoder. The use case in #20747 is to provide a RestTemplate to the decoder with custom proxy settings.
Comment From: mbhave
I'd initially thought adding a JwtDecoderCustomizer would work but that's not the case. We would need a JwtDecoderBuilderCustomizer to support customizations. The problem is that the JwtDecoder built when using an issuer location isn't built using a builder so that could cause some confusion around what can be customized and what can't.
Comment From: wilkinsona
I've just noticed that there also isn't a restOperations(RestOperations) method on the NimbusJwtDecoder.PublicKeyJwtDecoderBuilder. That makes sense as it doesn't make any HTTP calls. Perhaps #20470 isn't such a good driver for general purpose customization after all?
Comment From: mbhave
Yeah, the public key version doesn't need a restOperations. The issuerUri one, however, does use one but it doesn't appear to be customizable. Given that, I don't think we should add a general purpose customizer for the JwtDecoder.
Comment From: m-kay
Customization is only needed in the case if the JwkSetUriJwtDecoderBuilder is used, because all the other builders are fully configurable via properties. Therefore I think only a JwkSetUriJwtDecoderBuilderCustomizer would be needed as proposed in my branch gh-20750
Comment From: mbhave
Thanks for the proposal @m-kay. It is true that for the customizations that Spring Security currently supports, it is only the JwkSetUriJwtDecoderBuilder that needs a customizer. However, creating a JwkSetUriJwtDecoderBuilderCustomizer would be misleading because it would not be able to customize the restOperations used by JwtDecoders which calls the JwkSetUriJwtDecoderBuilder under the hood. I have raised a Spring Security issue about that. Until then, I don't think we should do anything in Spring Boot as there's a chance that we would back ourselves into a corner.
Comment From: ThomasKasene
If we can't get a customizer, perhaps it's possible to inject a OAuth2TokenValidator<Jwt> into the bean so we can supply our own custom validators if we need them? This is really cumbersome to achieve with the current setup as far as I can tell, and while I feel like it's due to Spring Security's tightly coupled configuration, maybe Spring Boot can make it less painful?
There's an old issue in Spring Security that describes the problem I'm facing: https://github.com/spring-projects/spring-security/issues/6909
It petitions to add a getValidator() to NimbusJwtDecoderJwkSupport to make it possible to know what validators have already been registered, but there doesn't seem to be enough traction to get it implemented.
Comment From: m-kay
any update on this? 👀
Comment From: wilkinsona
@m-kay As you can see above, @mbhave opened https://github.com/spring-projects/spring-security/issues/8365. If you read through that issue, you’ll see that it was closed in favour of https://github.com/spring-projects/spring-security/issues/8882. 8882 remains open and I don’t think we can do anything here without it so this issue remains blocked.
Comment From: wilkinsona
https://github.com/spring-projects/spring-security/issues/10309 has been scheduled for Spring Security 5.8 so we may be able to do something in this area in 3.0.x. I'm going to assign this issue to 3.0.x serve as a reminder to see what becomes possible. It'll remain blocked until the changes have been made in Security.
Comment From: wilkinsona
Some changes were made in Spring Security a couple of days ago so we should be able to do something in Boot now. It may be too late now for 3.1 though.
Comment From: wilkinsona
@mbhave there's a new NimbusJwtDecoder.withIssuerLocation(issuerUri) method that returns a JwkSetUriJwtDecoderBuilder. That means that both jwtDecoderByIssuerUri and jwtDecoderByJwkKeySetUri could now use a JwkSetUriJwtDecoderBuilder which allows RestOperations to be configured. We could offer a JwkSetUriJwtDecoderBuilderCustomizer now and I think it could be applied consistently. Do you think we should do so?
Comment From: wilkinsona
Possible implementation for discussion and review.