DefaultJwtParser ignores custom base64 parser it was built with in a scenario

[mbomeara]

In cases where a JwtParser is built using b64Url() to provide a custom base64 decoder, the expectation is that all base64 decoding will use the custom decoder:

Jwts.parser()
    .verifyWith(publicKey)
    .b64Url(decoder) // expect this decoder to be used for all base64 operations of parseSignedClaims()
    .build()
    .parseSignedClaims(jwt);

However due to https://github.com/jwtk/jjwt/blob/754324879d55a374856e9e5d48e028b906fa293a/impl/src/main/java/io/jsonwebtoken/impl/DefaultJwtParser.java#L644 a new DefaultJws is constructed. The constructor for DefaultJws is hard-coded to use its own base64 decoder (namely Decoders.BASE64URL):

https://github.com/jwtk/jjwt/blob/754324879d55a374856e9e5d48e028b906fa293a/impl/src/main/java/io/jsonwebtoken/impl/DefaultJws.java#L30

This violates the expectation that the custom base64 decoder will be used for all decoding. This behavior has changed somewhere between 0.11.5 and 0.12.5 which in turn breaks our application if we update our jjwt dependency version to the latest.

[lhazlewood]

Thanks for creating the issue!

While I agree we should correct this, it's not clear to me how this could 'break' an application.

The only thing the DefaultJws constructor does is take a Base64URL string and decodes it to a raw digest byte array so that array is then available via jws.getDigest(). And that DefaultJws instance is only returned from the parser if the signature is verified successfully first.

So as long as the signature string is actually Base64URL, JJWT's default decoder will accurately obtain the digest byte array, even if your specified Decoder isn't used.

So yes, we should change the implementation to decode using the specified Decoder, but I don't see how this could cause something to break in the application. Could you please explain how this occurs? Thanks!

[lhazlewood]

@mbomeara please see #948