Padding in Base64-encoded header/payload

[byronwolfman]

I recently became aware that JWTs issued by AWS Application Load Balancers are technically not spec-compliant, in that the base64-encoded components include padding:

These tokens follow the JWT format but are not ID tokens. The JWT format includes a header, payload, and signature that are base64 URL encoded, and includes padding characters at the end. An Application Load Balancer uses ES256 (ECDSA using P-256 and SHA256) to generate the JWT signature.

(via this doc on ALB user claims encoding and signature validation.)

The jwx v2 and v3 libraries therefore cannot verify these tokens, because when Parse() is called, the header and payload are decoded (successfully, regardless of padding) but then re-encoded without padding for the sake of the signature check. The signature applies to the padded version though, so the re-encoded (and unpadded) versions fail verification. To be clear I do not view this as a bug in jwx, nor do I expect it to automatically carve out a special case. I've been reading some of the other discussions here and see a strong commitment to following the spec, which I appreciate, given that this problem stems from an implementation that does not respect the spec.

What I'm wondering is if there's a recommendation on the "best" (or at least, least bad) way of dealing with padding in JWTs. Right now my approach is to manually verify the header+payload without jwx, and then call jwt.WithVerify(false). It's a few extra steps, but it works. I wonder if there's appetite though for options such as jwt.WithPadding(bool) or jwt.WithEncoding(*base64.Encoding)

I'm not convinced that adding these new options is a good idea though. Both essentially invite users to generate non-spec-conforming JWTs of their own, even accidentally (one wonders if ALBs ended up in this category). On the other hand, my approach with option 1 is to copy out portions of *ecdsaVerifier.Verify() to call directly before calling jwt.Parse() and while it works, it also seems kind of crude. I haven't found a way to call Verify directly (which I suspect is intentional) but if there were a way, then I suppose that would be the easiest onramp.

Anyway I'd love to hear if you think any of these are viable. If the answer is no, then that's all right too.

Thanks for an excellent library all the same.

[lestrrat]

@byronwolfman thanks. At first glance I'm okay with some sort of new option like jwt.WithEncoding.
Can you please provide some test cases that I can work with? I don't directly deal with AWS myself, so would be nice if you or somebody else could provide them. TIA

[lestrrat]

@byronwolfman try parsing an ALB User Claim using the code in #1328

tok, err := jwt.Parse(
   payload,
   jwt.WithKey(....),
   jwt.WithBase64Encoding(base64.URLEncoding),
)

[byronwolfman]

@lestrrat Thank you, that's brilliant. 🙏 All my test cases are passing! It will take me until later today to get this deployed into a real environment, but I am optimistic. Will let you know how it goes.

[byronwolfman]

@lestrrat Just deployed with that branch and it works! This was with no other changes other than passing jwt.WithBase64Encoder(base64.URLEncoding) when parsing.

[lestrrat]

@byronwolfman Thanks, I will need to do some more tweaking, but I think the top-level API looks good as is. Will probably merge it into v3 soon

[byronwolfman]

@lestrrat Closing the loop: I've re-deployed against the v3.0.0-beta2 release and everything works. Thank you for this enhancement!