Allow for custom rest template

[Budlee]

No description provided.

[Budlee]

Reference to issue #5607

[jzheaux]

@Budlee, thanks for taking some time to think this through. Making RestTemplate more configurable here would certainly be nice.

This is still an open discussion, but the options I can see are:

ReactiveJwtDecoders#fromIssuerLocation(String issuer, RestTemplate rest)

or providing a new class that implements ReactiveJwtDecoderFactory:

public class IssuerReactiveJwtDecoderFactory implements ... {
    private final RestTemplate rest;

    @Override
    public ReactiveJwtDecoder createDecoder(String issuer) {
        // ...
    }

    public void setRestTemplate(RestTemplate rest) {
        // ...
    }
}

with equivalents needed for imperative.

Either way, I think that the Utils class may still move around a bit, so I'd prefer to keep that package-private as it is. AFAICT, it's not necessary to expose it.

As far as multi-tenancy, I think that your proposal doesn't yet address the use case you raised for having a different RestTemplate per issuer. To have something that sophisticated, I think you'd still need to supply your own AuthenticationManagerResolver<String> in the constructor.

Even still, it may be valuable to expose something like a ReactiveJwtDecoderFactory<String> in JwtIssuerReactiveAuthenticationManagerResolver, but that will probably depend on how the larger conversation about RestTemplate goes.

[rwinch]

Another option might be to allow the user to use RestTemplate directly.

[Budlee]

@jgrandja is there any decision on what is the way forward to expose this to the RestTemplate to the user? Is the idea to commit to #8624 as the solution

[jgrandja]

@Budlee I'm going to spend some time this week to figure out a solution. This one is a bit tricky as there are quite a few touch points in the code and a couple of special use cases.

[jgrandja]

@Budlee The original design intent for JwtDecoders and ReactiveJwtDecoders is that it was meant to be used as a utility class, hence the static methods. It was provided as a convenience for most use cases but not all. For more advanced use cases, eg. where you need to configure proxy settings for the underlying HTTP client, you can configure a JwtDecoder (or ReactiveJwtDecoder) and expose it as a @Bean - see example 1 and example 2.

After reviewing your PR, we do not want to expose JwtDecoderProviderConfiguration or provide a ReactiveJwtDecoders.fromIssuerLocation(String issuer, RestTemplate rest). This was never the design intent for JwtDecoders or ReactiveJwtDecoders.

I'm going to close this PR based on the above reasoning.