breaking change in 1.3.0 - strict base64url encoding

[joaovieira]

Gracefully handling base64 JWTs (as the ones issued by AWS Load Balancer Auth) was one of the reasons I picked this library vs https://github.com/auth0/node-jsonwebtoken as I had hit a dead end with it. See:
auth0/node-jsonwebtoken#514
auth0/node-jws#84

AWS fixed the base64url encoding, but still left the == paddings as mentioned in auth0/node-jws#84 (comment).

Version @panva/[email protected] broke this behaviour in the middle of another feature and is now behaving as the jsonwebtoken module here: 5b53cb0#diff-5322f259336be67d87b1447571f7de32

This now results in a JWTMalformed error for the same token.

Would you consider relaxing this check or support that padding so we can easily and safely migrate from 1.2.0?

Here is an example of a token issued by AWS that worked in 1.2.0, but stopped working in 1.3.0:

eyJ0eXAiOiJKV1QiLCJraWQiOiIyZTFkYjRmMC1mYmY5LTQxZjYtOGMxYi1hMzczYjgwZmNhYTEiLCJhbGciOiJFUzI1NiIsImlzcyI6Imh0dHBzOi8vaWRlbnRpdHktc3RhZ2luZy5kZWxpdmVyb28uY29tLyIsImNsaWVudCI6ImIyM2I0ZjM1YzIyMTI5NDQxZjMwZDMyYmI5ZmM4ZWYyIiwic2lnbmVyIjoiYXJuOmF3czplbGFzdGljbG9hZGJhbGFuY2luZzpldS13ZXN0LTE6NTE3OTAyNjYzOTE1OmxvYWRiYWxhbmNlci9hcHAvcGF5bWVudHMtZGFzaGJvYXJkLXdlYi80YzA4ZGI2NDMyMDIyOWEyIiwiZXhwIjoxNTYyNjkxNTg1fQ==.eyJlbWFpbCI6ImpvYW8udmllaXJhQGRlbGl2ZXJvby5jby51ayIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJmYW1pbHlfbmFtZSI6Ikd1ZXJyYSBWaWVpcmEiLCJnaXZlbl9uYW1lIjoiSm9hbyIsIm5hbWUiOiJKb2FvIEd1ZXJyYSBWaWVpcmEiLCJwaWN0dXJlIjoiaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tLy1sTUpXTXV3R1dpYy9BQUFBQUFBQUFBSS9BQUFBQUFBQUFCVS9lNGtkTDg5UjlqZy9zOTYtYy9waG90by5qcGciLCJzdWIiOiIxMWE1YmFmMGRjNzcwNWRmMzk1ZTMzYWFkZjU2MDk4OCIsImV4cCI6MTU2MjY5MTU4NSwiaXNzIjoiaHR0cHM6Ly9pZGVudGl0eS1zdGFnaW5nLmRlbGl2ZXJvby5jb20vIn0=.DSHLJXLOfLJ-ZYcX0Vlii6Ak_jcDSkKOvNRj_rvtAyY9uYXtwo798ZrR35fgut-LuCdx0aKz2SgK0KJqw5q6dA==

Thanks

[panva]

@joaovieira i'm sorry this has caused you trouble, but it was always the intention to only accept well-formed tokens and i'm sad you relied on it - was that just a try and see if it works on your end or did something in the documentation tipped you off that it would work?

What AWS is issuing is not a valid JWT by the book so you may have to stick to locking down the @panva/jose version to e.g. v1.0.2 which didn't get deprecated before this was fixed.

I would definitely suggest to knock down on AWS doors and have them fix their tokens.

JWT, using compact serialization of JWS must follow the encoding rules defined in the specification.

Base64url Encoding
      Base64 encoding using the URL- and filename-safe character set
      defined in Section 5 of RFC 4648 [RFC4648], with all trailing '='
      characters omitted (as permitted by Section 3.2) and without the
      inclusion of any line breaks, whitespace, or other additional
      characters.  Note that the base64url encoding of the empty octet
      sequence is the empty string.  (See Appendix C for notes on
      implementing base64url encoding without padding.)

[joaovieira]

Not that I remember. Just felt auth0 was being too tight, even with their comments, and your library handled it gracefully.

I understand that and will try reaching out to AWS as well.

Just thought it could be a bit more forgiving as other languages apparently: auth0/node-jws#49 (comment). We also use other Ruby and Scala libraries that can handle them.

On another note, would be good to have the security fix without the breaking change - so also wanted to raise that.

[panva]

@joaovieira I understand and thank you for bringing it up, that being said a bug fix may be breaking when the usage it is fixing was never intended to work. Were the acceptance of ill-formed tokens documented and pointed out as a feature I wouldn't consider tightening the ruleset without a major version bump.

It would be great if AWS followed the standard they actually claim to issue tokens as, they say in their doc its JWT, but its not :) JWT's are without padding.

Just felt auth0 was being too tight

Interoperability between standards implementations is not easy to achieve, in many cases issues arise from ambiguity in the standards, that's not the case here though. Also, auth0 did not answer those linked tickets, i can only see contributors, not owners ;)

[panva]

@joaovieira 470b4c7 and eae01b5 released with v1.22.1 reverted this.

I'm done trying to educate other JOSE producers about interoperability so i'm going to be accepting their non-conform base64url so that users of this module don't suffer performance loss.