Undocumented breaking change in v3 regarding base64url padding strictness

[daltones]

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.

• In v2, JWSSerializerManager::unserialize() throws InvalidArgumentException: Unsupported input.
• In v3, 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 by Base64UrlSafe::decode() calls.

The problem is that Base64Url (from spomky-labs/base64url) is padding-strict since it uses PHP's built-in base64_decode(), and Base64UrlSafe (from paragonie/constant_time_encoding) is not padding-strict by default (there is a flag on the ::decode() method).

[Spomky]

Hi,

I agree. The encoding should not deviute from the specification. This will be fixed in the current minor version.

[Spomky]

Addresse in #497. Will be tagged soon.

[github-actions[bot]]

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.