fromCompact fails if there are Base64 padding characters.

[phadej]

I have to validate tokens generated by 3rd party (=AWS) which contains padding characters in their compact form.

The base64-bytestring-1.2.0.0 decode works leniently about padding:

*Main> Base64.URL.decode "Zm91cg=="
Right "four"
*Main> Base64.URL.decode "Zm91cg"
Right "four"

---

Relevant spec portions: https://tools.ietf.org/html/rfc7515#section-2

   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.)

3.2.  Padding of Encoded Data

   In some circumstances, the use of padding ("=") in base-encoded data
   is not required or used.  In the general case, when assumptions about
   the size of transported data cannot be made, padding is required to
   yield correct decoded data.

   Implementations MUST include appropriate pad characters at the end of
   encoded data unless the specification referring to this document
   explicitly states otherwise.

   The base64 and base32 alphabets use padding, as described below in
   sections 4 and 6, but the base16 alphabet does not need it; see
   section 8.

[frasertweedale]

@phadej thanks for the report.

Well, these are not valid tokens. I am not going to change hs-jose to accept these invalid tokens because:

• The JOSE spec is unambiguous: padding chars are not to be included. I don't get any satisfaction or compensation spending my cycles to work around Big Cloud's basic errors. It is their issue to fix, and they have resources to do it.

• More importantly, it is possible (even likely) that the AWS implementation is broken in other ways, e.g. that it includes padding in the signing input. Therefore accepting padding when decoding the compact serialisation may result in a token that does not validate, because when hs-jose constructs the signing input it will (correctly) omit padding. We've seen this sort of bug before, e.g. see https://github.com/frasertweedale/hs-jose/issues/97#issuecomment-687654903 and https://github.com/frasertweedale/hs-jose/issues/99.

It is probably not a satisfying outcome for you, but the second point (albeit unconfirmed) is especially fatal. I'm going to close this issue. If you have any other commentary or especially if there are links to any public tickets tracking the AWS bug please comment.

Cheers, Fraser

[frasertweedale]

Not sure if it is the same service but here's a report of token from some AWS service that exhibits this issue and, indeed, confirms that validation is also busted because the padding appears in the signing input:

https://stackoverflow.com/questions/60246585/unable-to-verify-jwt-coming-from-aws-alb-authentication

[frasertweedale]

Another report: https://github.com/auth0/node-jws/pull/84

[phadej]

I agree.

It would be nicer if JWS spec elaborated the BASE64URL padding issue using MUST-RFC2119. E.g. saying explicitly that compact forms with padding characters in base64url encoding MUST be rejected. I don't find it completely unambiguous that padding characters must not be included. It can be interpreted as they could and they SHOULD (which is not strict requirement) be omitted. Again, there is no RFC2119 verbs used, so AWS people could (and probably would if one contacts them) argue whether the 2. Terminology section is normative or informative. (It does looks like latter).

Is there way to ask IETF to produce clarifications / errata on the issue?

[frasertweedale]

Personally I do not see any ambiguity, but RFC2119 language would be an improvement. You can report errata here: https://www.rfc-editor.org/errata.php