follow rfc 7515 : strip padding from JWS segments

[adityanatraj]

Preface

So, I was writing something that used this library to sign JWTs in GCP to authenticate with Vault using the GCP engine. While I was able to generate tokens (parsing them locally) just fine, I was failing authentication with an error regarding illegal byte sequences during base-64 decoding.

Turns out the vault plugin, which is written in Go, uses a RawUrlEncoding to decode the incoming JWT. My tokens were failing to decode because each segment included the = padding. Oh.

Why this PR

According to the RFC 7515:

Base64 encoding [... has] all trailing '=' characters omitted (as permitted by Section 3.2)
and [is] without the inclusion of any line breaks, whitespace, or other additional
characters. ... (See Appendix C for notes on
implementing base64url encoding without padding.)

and unfortunately taking a look at the python stdlib urlsafe_b64encode function's docs:

The result can still contain =.

Also, it's kinda funny that there's a function padded_urlsafe_b64decode, perhaps missing an un- in its name, to re-pad unpadded segments on the decoding side noting:

Google infrastructure tends to omit the base64 padding characters.

As I've learnt recently, it appears to follow the spec. Is there historical knowledge I might not know as to why this was implemented differently?

What

This PR:

• strips off trailing ='s from encoded chunks during creation
• adds a test to confirm it encodes, strips and does no damage

[theacodes]

Also, it's kinda funny that there's a function padded_urlsafe_b64decode, perhaps missing an un- in its name, to re-pad unpadded segments on the decoding side noting:

I think the naming comes from the fact that it adds in the "missing" padding automatically. But honestly I'm not picky.

As I've learnt recently, it appears to follow the spec. Is there historical knowledge I might not know as to why this was implemented differently?

Yeah, it follows the spec now. This function was ported form oauth2client which was ported from the google apiclient and then from the nameless arts before. Google infrastructure was using paddingless urlencoded strings before the JWT RFC (2015), so that might posit on possible explanation.

At any rate, this is a great change- thank you for doing it. I'm merging. :)

[adityanatraj]

Thanks for the historical details and for the merge!