Allow configuring custom validator for Jwt client assertion

[atjohn-csam]

Expected Behavior
It would be great if we could add a custom claim validator for client authentication using JWT assertion. This will allow additional validations to be done on the jwt assertion authentication.

Current Behavior
Right now for client authentication using JWT Assertion, DelegatingOAuth2TokenValidator comes with the default validators: return new DelegatingOAuth2TokenValidator<>(
new JwtClaimValidator<>(JwtClaimNames.ISS, clientId::equals),
new JwtClaimValidator<>(JwtClaimNames.SUB, clientId::equals),
new JwtClaimValidator<>(JwtClaimNames.AUD, containsProviderAudience()),
new JwtClaimValidator<>(JwtClaimNames.EXP, Objects::nonNull),
new JwtTimestampValidator()

Context
In this implementation, the clients will send JWT assertions with custom claims which I am planning to validate before issuing the access token. I haven't found away to configure this.

[jgrandja]

Thanks for the request @atjohn-csam. We'll look at adding this customization hook.

[atjohn-csam]

Hi @jgrandja Can I work on this feature?

I am thinking of introducing DefaultJwtAssetionValidatorFactory to JwtClientAssertionAuthenticationProvider which will have the set of existing validators (new JwtClaimValidator<>(JwtClaimNames.ISS, clientId::equals),
new JwtClaimValidator<>(JwtClaimNames.SUB, clientId::equals),
new JwtClaimValidator<>(JwtClaimNames.AUD, containsProviderAudience()),
new JwtClaimValidator<>(JwtClaimNames.EXP, Objects::nonNull),
new JwtTimestampValidator()), along with a new optional JwtClaimValidator which the user can configure. Is this how you envisioned this to be done?

[jgrandja]

Thanks for your interest @atjohn-csam.

We're holding off on adding new features and enhancements until after we release 0.3.0.

Our top priority for 0.3.0 is to deliver the initial version of the reference documentation.
We still have a lot of work to do so we need to keep focused.

Please reach out again after 0.3.0 is released May 23.

[jgrandja]

Related gh-897

[jgrandja]

@atjohn-csam This is now resolved via gh-944. Please see comment.

Closing this as a duplicate.