A custom JWTClaimsVerifier is ignored if it doesn't override verify with context

When extending DefaultJWTClaimsVerifier and overriding only the verify(JWTClaimsSet claimsSet) leads to this custom verifier being ignored during JWT processing.

So assuming there is this custom JWT claims verifier looking something like:

public class MsiClaimsVerifier<C extends SecurityContext>
    extends DefaultJWTClaimsVerifier<C> {

    public MsiClaimsVerifier(String requiredAudience, JWTClaimsSet claimsSet, Set<String> requiredClaims) {
        super(requiredAudience, claimsSet, requiredClaims);
    }

    @Override
    public void verify(JWTClaimsSet claimsSet) throws BadJWTException {
        super.verify(claimsSet)
        throw new BadJWTException("THIS IS A TEST");
    }
}

And we use it and process the JWT:

jwtProcessor.setJWTClaimsSetVerifier(msiClaimsVerifier);
jwtProcessor.process(token, null);

The exception in the overriden method will never be thrown because the DefaultJWTProcessor expects the custom verifier to override a different signature of the method (this is from the library):

private JWTClaimsSet verifyClaims(final JWTClaimsSet claimsSet, final C context)
        throws BadJWTException {

        if (getJWTClaimsSetVerifier() != null) {
            getJWTClaimsSetVerifier().verify(claimsSet, context);
        } else if (getJWTClaimsVerifier() != null) {
            // Fall back to deprecated claims verifier
            getJWTClaimsVerifier().verify(claimsSet);
        }
        return claimsSet;
    }

Since I’m not using the SecurityContext anywhere I didn’t even think of using the signature that accepts it. And it took me several hours to figure it out and make it work.

Not a major bug, but I haven’t seen this mentioned anywhere. Maybe deprecating verify(JWTClaimsSet claimsSet) as well would work? Or null-check the context and act accordingly?

‌

Used version 9.7 of the library

Comments (3)