feat: add defaultAlg param

[bshaffer]

Add parameter to JWK::parseKeySet and JWK::parseKey to prevent "missing alg" error.

$defaultAlg = 'RS256'; // default algorithm used when "alg" isn't set
$jwks = JWK::parseKeySet($jwks, $defaultAlg);

See https://github.com/firebase/php-jwt/pull/376/files#r861654996

[bshaffer]

cc @Nextra

[Nextra]

This would certainly make using the parseKeySet easier without having to manually go through the key set before passing it over, which is enough for the Microsoft example I mentioned.

I have a question that I didn't quite find an obvious answer to in the code:

Prior to the change, did "kty": "RSA" always lead to RS256 being used, or was a JWK with just kty set able to "handle" all variants of the matching algorithm? I guess this boils down to why alg is marked optional in the first place, and if either the strict or the new defaultArg solution prevents a user of this library from utilizing (exploiting) a "feature" of the spec.

[bshaffer]

@Nextra the value of kty has never been used to determine the algorithm, it's only ever been used to decode the public key. Prior to this change, the user was required to specify the "allowed algorithms" when calling JWT::decode in addition to supplying the keys array from the result of JWK::parseKeySet. So the user would have manually passed 'RSA256' in as an allowed algorithm. Since we've removed the allowed algorithms, we require each public key to be explicitly tied to an algorithm, so at the time the JWKs are parsed, we need to know their expected algorithm.

I am not sure how this could be exploited by anyone. I agree that it's strange that "alg" is optional in the first place, but I assume it's because many JWKS's have a known algorithm type, and so it's unnecessary to define it twice.

[Nextra]

The way I could see it as being useful is if one JWK were to be usable for decoding all variants of the respective algorithm, so passing ['RS256', 'RS384', 'RS512'] into the allowed algorithms with just one matching RSA JWK.

I don't know if that makes any sense.

[bshaffer]

We no longer use an array of "allowed algorithms", because the keys must be tied to an algorithm when they're used to verify the JWT. So to me, your suggestion does not make sense.

[Nextra]

Thought as much. Thanks for the change!