Closed daltones closed 9 months ago
Hi,
I agree. The encoding should not deviute from the specification. This will be fixed in the current minor version.
Addresse in #497. Will be tagged soon.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Description
I'm in the process of migrating
web-token/jwt-*
packages from v2 to v3 and a test case of my project showed that base64url decoding isn't padding-strict anymore.To give more context: we have our own component to create or verify JWS tokens, but that is just a wrapper for
web-token/jwt-signature
functionality. And that component's test cases also cover malformed tokens.The test that is not passing refers to a JWS token with valid header and signature parts and a payload part that is not valid base64url content regarding padding.
JWSSerializerManager::unserialize()
throwsInvalidArgumentException: Unsupported input.
JWSSerializerManager::unserialize()
returns fine with some payload.I noticed that this behavior change was introduced in https://github.com/web-token/jwt-framework/commit/ab78fbb73a7d144b89668f9c6f61133008d31346, in which several
Base64Url::decode()
calls were simply replaced byBase64UrlSafe::decode()
calls.The problem is that
Base64Url
(fromspomky-labs/base64url
) is padding-strict since it uses PHP's built-inbase64_decode()
, andBase64UrlSafe
(fromparagonie/constant_time_encoding
) is not padding-strict by default (there is a flag on the::decode()
method).