I just learned the hard way that the last char of a JWT signature can be modified and still be valid. After a lot of manual debugging, I figured out the hard way that it is in fact the normal behaviour for JWTs with certain signature types, and has to do with the base64 encoding implementation. Here is the best explanation I've found. Essentially in JWT base64 decoding, if there are extra bits, they are ignored. So for the n bits that are ignored in a signature, there are 2^n possible valid signatures. It occured to me that there is an interesting consequence of this, that if you ever wanted to revoke/block a particular JWT token, you could not simply blacklist the token's value, as there will still be 2^n-1 other valid strings encoding the same signed JWT token.

I could imagine this being relevant if a long-lived high-profile JWT token leaked publically. The obvious fix, blacklisting that leaked token, would also be utterly insufficient! (Knowing about this obscure quirk, you can easily accomplish the same thing correctly by blacklisting and comparing the token[:-1] instead of the full string)