NimbusReactiveJwtDecoder should accept a custom processor

[jzheaux]

The Nimbus JwtDecoders, both servlet and reactive, simplify Nimbus configuration by exposing some basic use cases like using a JWK Set Uri or by using a single public key.

Many scenarios are more complex than this, and Nimbus is a full-featured API that allows users to configure for these more complex scenarios.

#5648 proposes addressing this on the servlet side by introducing a constructor that accepts a JWTProcessor instance.

Because of certain preprocessing that NimbusJwtReactiveDecoder does in order to maintain its non-blocking nature as it interacts with Nimbus, it is not yet clear how we might expose the JWTProcessor there; though coordinating with the Nimbus team may bear some fruit.

UPDATE: Creating a Converter from scratch that reactively exercises the Nimbus API can be a challenge:

Converter<SignedJWT, Mono<JWTClaimSet>> processor = // ... tricky business
NimbusReactiveJwtDecoder jwtDecoder = new NimbusReactiveJwtDecoder(processor);

So, as part of this ticket, let's also expose a builder for simply working with the keyset:

Function<JWT, Flux<JWK>> jwkSource = // ... reactive way to obtain key set
NimbusReactiveJwtDecoder jwtDecoder = 
        NimbusReactiveJwtDecoder.withJwkSource(jwkSource).build();

[GregoireW]

Hello,

I made an attempt to solve this: PR #6367

From the fact that:

• JWTProcessor can depends on reactive result. We need something to provide those
• JWTProcessor is only used to provides JwtClaimsSet

For me there is only two solution. Either the decoder take a function SignedJWT -> Mono<jwtClaimsSet> but it means that the decoder will do almost nothing.

Or the decoder take an optional option that provide the context (computed from the JWT header) so that we can call processor process method correctly.

I choose to write this code.

Now writing the nimbus reactive jwt decoder can be painful.
It is why I provides a "factory" class that can create the instance from the previous existing constructor (from RSA public key or JWKS url).

I'm convince that there could be a "technically" better solution, but I'm not sure it will better to use it.

[jzheaux]

I'm not sure that exposing NimbusReactiveJwtDecoder's context-creating is a good idea. This is definitely a workaround for Nimbus lacking a non-blocking JWK retrieval API.

Ideally, Nimbus would add a non-blocking API, and perhaps there is an opportunity for the community to help with that.

Another possibility might be to introduce ReactiveJWTProcessor into Spring Security:

public interface ReactiveJWTProcessor<C extends SecurityContext> {
    Mono<JWTClaimSet> process(SignedJWT signedJWT, C context);
}

with a default implementation that performs the same workaround that NimbusReactiveJwtDecoder does today. Then, NimbusReactiveJwtDecoder could take ReactiveJWTProcessor as a constructor parameter.

It would help to know what particular problem you are trying to solve, @GregoireW. What is your specific need for passing in your own JWTProcessor to NimbusReactiveJwtDecoder?

[GregoireW]

I wrote in my previous message that I saw 2 way of solving the issue. First is like you say with the interface.
Note that the context is not required in this case as it is linked to the processor and will be hidden in the implementation (else we need to get a context from somewhere so it is like the implementation I wrote)

public interface ReactiveJWTProcessor {
    Mono<JWTClaimSet> process(SignedJWT signedJWT);
}

or the one I write in the PR with a processor and a initializer. In this use case, processor and initializer are coupled a little bit (not so great yes but ...)

I choose the processor + initializer only because

• sometime initializer is not needed
• I guess we can have a key selection business much more complex than the default code (what happens if I got a JWKS that reference RS256 key, then RS512 key then ECDSA-P256) followed by a simple processor.

But It is clearly a pure tail/head choice.
If you prefer an interface with

Mono process(SignedJWT signedJWT);

it is a simple refactoring. I can do it. ( who validate? )

Now going back to my usecase:

• I'm not sure my identity provider will stay on the RS256 signature mode.
• Most of the application we wrote in my organization are behind corporate proxy. I need to push the key to the context in a reactive way, then call the nimbus processor. Today, the RemoteSource is not so great to setup. I add a small "WebClient" parameter to be able to fix that.

PS: I just saw that I got 2 errors in the build, I will check that...
EDIT: It was 1 typo + the test with springboot... On this one, as I did something with breaking change, there is no way the process will be ok without a really dirty thing....(breaking change or dirty hack) ... which I'm really not proud to have done.... ( one way, protected getter on the factory is better but if it is a deprecated thing in xxx version (no need to set versions here :D ) , I hope quality guy are a little bit blind :D )

       @Deprecated
	public NimbusReactiveJwtDecoder(String jwksUri){
		NimbusReactiveJwtDecoder r= NimbusReactiveJwtDecoderFactory.fromJWKS(jwksUri);
		this.jwtProcessor=r.jwtProcessor;
		this.initializer=r.initializer;
	}

[jzheaux]

I think let's go for our ideal first, which is to coordinate with Nimbus. They've been open to our suggestions and PRs in the past.

If we can't find a path forward with them, then we can look at a PR.

In the meantime, I think that your code will end up being fairly minimal to implement ReactiveJwtDecoder yourself so that you can retrieve your key in the way that you need to.

[jzheaux]

I've opened a ticket with Nimbus and we'll see where that goes: https://bitbucket.org/connect2id/nimbus-jose-jwt/issues/296/consider-having-jwtprocessor-accept-key