JwkSourceReactiveJwtDecoderBuilder should be typed SignedJWT instead of JWT

[jgrandja]

We should consider removing NimbusReactiveJwtDecoder.JwkSourceReactiveJwtDecoderBuilder since it's not used.

I also noticed that the equivalent does not exist in NimbusJwtDecoder.

If we decide to keep it than we should change the generic types from Function<JWT, Flux<JWK>> to Function<SignedJWT, Flux<JWK>>.

[jzheaux]

Agreed that it should be SignedJWT.

This implementation addresses #6367 and is intended to simplify the construction of a Converter<SignedJWT, Mono<JWTClaimSet>>. Constructing one of these is more complex than a JWTProcessor (the rough NimbusJwtDecoder equivalent) because the user can't simply supply an implementation of JWKSource when configuring it.

With traditional Nimbus, the user can customize key retreival like so:

JWKSource<SecurityContext> jwkSource = // use a Nimbus implementation or customize
JWSKeySelector<SecurityContext> jwsKeySelector =
		new JWSVerificationKeySelector<>(jwsAlgorithm, jwkSource);
DefaultJWTProcessor<SecurityContext> jwtProcessor = new DefaultJWTProcessor<>();
jwtProcessor.setJWSKeySelector(jwsKeySelector);
NimbusJwtDecoder jwtDecoder = new NimbusJwtDecoder(jwtProcessor);

However, with reactive, it's quite a bit more roundabout, using the Nimbus API in a counter-intuitive way:

Function<SignedJWT, Flux<JWK>> reactiveJwkSource = // get the keys reactively
JWKSecurityContextJWKSet jwkSource = new JWKSecurityContextJWKSet();
JWSKeySelector<JWKSecurityContext> jwsKeySelector =
		new JWSVerificationKeySelector<>(this.jwsAlgorithm, jwkSource);
DefaultJWTProcessor<JWKSecurityContext> jwtProcessor = new DefaultJWTProcessor<>();
jwtProcessor.setJWSKeySelector(jwsKeySelector);
Converter<SignedJWT, Mono<JWTClaimSet>> reactiveJwtProcessor = signedJWT -> 
        reactiveJwkSource.apply(signedJWT)
                .collectList()
                .map(jwks -> createClaimSet(jwtProcessor, signedJWT, new JWKSecurityContext(jwks)));
NimbusReactiveJwtDecoder jwtDecoder = new NimbusReactiveJwtDecoder(reactiveJwtProcessor);

I believe it would be challenging and cumbersome for the user to configure the decoder in this way. So, they can instead do:

Function<SignedJWT, Flux<JWK>> reactiveJwkSource = // get the keys reactively
NimbusReactiveJwtDecoder jwtDecoder = NimbusReactiveJwtDecoder
    .withJwkSource(reactiveJwkSource).build();

Since the primary configuration of a NimbusXXXDecoder is to indicate the key retreival strategy, this seems like a reasonable abstraction to expose.

Of course, we could add NimbusJwtDecoder#withJwkSource(JWKSource<SecurityContext> jwkSource) for symmetry, but I don't see the same need since setting a JWKSource on a blocking JWTProcessor is quite straightforward.

For some extra context, the original impetus was from some requirements outlined by @GregoireW.

If you are agreed that we should keep it and simply change the parameter type from JWT to SignedJWT, I'd propose changing the description in this ticket to indicate as much and then make it a first-timers-only ticket since it would be quite a simple change.

[jgrandja]

Thanks for the explanation @jzheaux. This makes sense. We only need to change Function<JWT, Flux<JWK>> to Function<SignedJWT, Flux<JWK>>. I updated the ticket.

[alurysharad]

Hello
Is anyone working on this ?

Thank you
Sharad

[jzheaux]

@alurysharad, no, are you interested in submitting a PR for it?

[alurysharad]

Yes