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?
Let me try to reproduce it and potentially discuss it with our developer support team what’s the reasoning behind such behaviour. I’ll get back to you once i have any updates!
Sorry it took me such a long time but we were a bit bandwidth constraint. I managed to reproduce it the way you described it. Let me discuss and research it internally so we can have more info regarding that case!
It seems that it’s probably for the fact that if the issue presents itself only when changing the last character it’s very likely to be related to base64 encoding.
A different encoding (in the last character) may still give the same binary data when decoded.