require a non-empty key to decode a JWT

[sjones608]

In testing this library for use on a project, I was surprised when JWT::decode returned a successfully decoded payload even when an empty key was supplied. I mistakenly supplied an empty key b/c I accidentally referred to it in a config file by the wrong name.

I would think that an empty key should be an error. Otherwise, it would be possible to deploy an application using this library and have all tokens be successfully decoded, regardless of what key was used to encode them. As mentioned above, this could happen through accidental mishandling of configuration files.

I could be wrong about this and an empty key might be possible by design. If so, nevermind, and I'll just be more careful. ;-)

I've made the code changes to JWT::decode and added 2 new tests to verify that empty keys generate exceptions.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[sjones608]

I've signed the CLA

[jayhaase]

This code change should have also updated the function header which now incorrectly describes the parameters and thrown exceptions.

[scrobbleme]

Hi,
I'm not familiar with JWT, but I think from the documentation it reads that verification is a "should".
(I'm not sure, if this is the correct part of the doc as well)
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-13#section-5.3

[sjones608]

@scrobbleme That section of the IETF draft is entitled "Replicating Claims as Header Parameters". I read it to refer to situations where some of the claims that are inside an encrypted JWT are also sent as unencrypted headers. The verification of the unencrypted headers against the actual claims inside of the JWT is what "should" be done while verification of the claims in the actual JWT is a "must".

[scrobbleme]

@sjones608 Thanks for the explanation. Quite hard to understand.

As I'm not familiar with JWT but have to use it, I try to explan, why I thought it might be optional ;)

• I'm developing using Atlassian Connect. They use JWT, so I have to too.
• There you have to decode the token before verification, as you need a value from the token to retrieve another value, which is needed for the verification (stupid, isn't it?).
• Just read at "Exposing a Service"

Beside this I managed to figure out, how I still get the information I need:

$splitted_jwt = explode('.', $_GET['jwt']);
        $header = \Firebase\JWT\JWT::jsonDecode(\Firebase\JWT\JWT::urlsafeB64Decode($splitted_jwt[0]));
        $claims = \Firebase\JWT\JWT::jsonDecode(\Firebase\JWT\JWT::urlsafeB64Decode($splitted_jwt[1]));
        $signature = \Firebase\JWT\JWT::urlsafeB64Decode($splitted_jwt[2]);