Changing the last character of an encoded JWT, within a limited range, does not necessarily cause the token to be invalid — it still validates. I first encountered this behavior in the firebase/php-jwt library, however, the behavior is present in the live demo on https://jwt.io/ as well.
to reproduce: change the last character of the encoded JWT (e.g., on jwt.io, change the last character of the encoded token (“c”) to “d”, “e”, or “f”). Choose a character that is adjacent/close to the original character; you may have to experiment a bit but I’ve tried a dozen or so and was able to find such a working substitution quickly in all cases.
expected: JWT verification should fail.
actual: JWT verification succeeds.
I found a similar question here:
The above issue was closed as being implementation-specific. However, since the behavior is present in the reference implementation, I don’t believe that was the correct resolution.
Anyone have insights here? Is this a bug or some side effect of the verification process?