Spring Security Support customization of BearerTokenResolver in JwtIssuerAuthenticationManagerResolver

Expected Behavior

It should be possible to set or customize the BearerTokenResolver inside the JwtIssuerAuthenticationManagerResolver

Current Behavior

The customization is not possible.

Context

I have to support multiple token issuers and bearer tokens in query parameters. I would like to use the new JwtIssuerAuthenticationManagerResolver but I cannot alter the "allowUriQueryParameter" property of the DefaultBearerTokenResolver which is being used inside the JwtIssuerAuthenticationManagerResolver.JwtClaimIssuerConverter class.

Comment From: jzheaux

Thanks for the report, @marci74. I think what needs to be done here is to remove the dependency on the bearer token resolver altogether.

Since the resolver can return an AuthenticationManager, it could return one that retrieves the token from the given authentication, e.g.:

public AuthenticationManager resolve(HttpServletRequest request) {
    return authentication -> {
        BearerTokenAuthenticationToken token = (BearerTokenAuthenticationToken) authentication;
        String issuer = this.issuerConverter.convert(token);
        // ...
        return authenticationManager.authenticate(token);
    };
}

Something similar can be done on the reactive side as well.

Would you be interested in filing a PR to address this?

Comment From: AbstractConcept

@jzheaux I have run into a very similar issue.

Using an external oauth2ResourceServer, in a multi-tenant environment, it should be possible to override / select a custom JwtAuthenticationProvider with a custom JwtAuthenticationConverter, as not all of the JWT tokens are the same, and this leads to errors.

Currently, according to the official documentation (https://docs.spring.io/spring-security/site/docs/current/reference/html5/#oauth2resourceserver-multitenancy), if there is a need to support multi-tenancy by JWT Claim, one can use JwtIssuerAuthenticationManagerResolver that has to be configured by a class extending WebSecurityConfigurerAdapter, however, it comes with an overriden

public AuthenticationManager resolve(String issuer) method in the TrustedIssuerJwtAuthenticationManagerResolver static class, that contains: 1) a predefined, hardcoded JwtAuthenticationProvider, 2) which in turn contains a predefined, hardcoded JwtAuthenticationConverter, 3) which in turn contains a predefined, hardcoded JwtGrantedAuthoritiesConverter, the root of my problems.

Normally, the issue could be solved by configuring a Customizer<JwtConfigurer> within the HttpSecurity DSL, but OAuth2ResourceServerConfigurer runs the validateConfiguration() method that throws an IllegalStateException because, quote:

If an authenticationManagerResolver() is configured, then it takes precedence over any jwt() or opaqueToken() configuration

That's of course understandable, however, there should be a way to configure your own Customizer/JwtGrantedAuthoritiesConverter.

Currently, I have solved my own issue by using my own implementation of a JwtIssuerAuthenticationManagerResolver, that I have used instead of the 'official' one, that basically creates a new JwtAuthenticationConverter and sets my custom JwtGrantedAuthoritiesConverter, but I am willing to work on a PR, to provide a more "official" solution.

Some additional information would be great though: could the solution be based on allowing the end-user to provide his own BearerTokenResolver / JwtAuthenticationProvider, that will take priority over the default one?

EDIT: This could potentially be related to 6778 but I'm not sure if anything came from it.

EDIT2: Upon further investigation, the issue is not strictly the same, but very similar; the author had a problem with a hardcoded DefaultBearerTokenResolver in the JwtIssuerAuthenticationManagerResolver.JwtClaimIssuerConverter and I had the issue with a hardcoded JwtAuthenticationProvider in the JwtIssuerAuthenticationManagerResolver.TrustedIssuerJwtAuthenticationManagerResolver

Nonetheless, I can work on that.

Comment From: jzheaux

Sounds great, @AbstractConcept, the issue is yours.

Comment From: jzheaux

How is this coming, @AbstractConcept? Are you still able to provide a PR?

Comment From: AbstractConcept

@jzheaux Yes, apologies for the delay. The PR should be submitted by the end of this week (at the latest).

Comment From: jzheaux

Is this something you are still wanting to contribute, @AbstractConcept?

Comment From: AbstractConcept

Sometimes life gets in the way, unfortunately. If this is still a valid issue, and hasn't been fixed yet with some other PR, I got the code ready. Let me know if this still waits for a fix, and I'll create a PR. @jzheaux

Comment From: jzheaux

@AbstractConcept, yes, a PR is still welcome. Thanks for checking.