fix: use PKCS8 by default for ID token verify

[marickvantuil]

This is (hopefully) a fix for #457.

It happens specifically with phpseclib 3.x.

---

When using the AccessToken class to decode an ID token, the "Federated Sign On" certificates are stored in the PKCS8 format after which the ID token is decoded with Firebase/JWT:

$payload = $this->callJwtStatic('decode', [
    $token,
    $keys,
]);

Source: AccessToken.php#L246

Part of decoding the JWT is verifying the token which happens with openssl_verify:

$success = \openssl_verify($msg, $signature, $keyMaterial, $algorithm);

Source: JWT.php#L306

I have to be honest that I am completely lacking any knowledge about RSA keys and their encoding, but according to this StackOverflow issue PHP OpenSSL only accepts "public key in X.509 style". I can confirm this as I am getting the error "Supplied key param cannot be coerced into a public key" (same as in the linked issue at the start of this comment). After returning the key in PKCS8 format, the issue was fixed.

I understand my assessment of the issue might be completely wrong but I really like to help resolve this issue! 👍

[bshaffer]

So, this has to do with the format in which the key is passed to openssl_verify. I suppose it's possible that your implementation doesn't support PKCS1? I find that strange, but I am not sure what the implications are across all our users and platforms.

the "Federated Sign On" certificates are stored in the PKCS8 format

This is a bit misleading - the certs aren't stored in this format, but they are converted to PKCS1 format from the oauth2 certs URL for openssl.

I don't want to just change the format being returned, because it could have a negative affect on some platforms. A better solution would be to:

1. detect the version of OpenSSL and/or whether or not PKCS1 and PKCS8 are supported, and use the best one
2. add a $format option to verify to allow modification (not preferred)
3. confirm with 100% confidence that this update would not break (I doubt this is possible)

[marickvantuil]

Thanks for your reply @bshaffer!

I suppose it's possible that your implementation doesn't support PKCS1

After some more investigation, I found it throws this error when OpenSSL 1.1.1 is used. When I bump the PHP version (in my case from 8.1.12 to 8.1.13 using php:8.1.12-cli-alpine Docker image), OpenSSL is updated to 3.x and then it seems to work fine.

So I'm not sure what the implications are! As far as I understand it then, something has changed in OpenSSL 3.x which fixes this issue but some other PHP 8.1 builds (depending on how it was built) ship with 1.1.1 in which this error happens. Hope I'm right here!

Not sure if it helps, but I set up a reproducable example here.

Output: