Add support for determining key based on entire JOSE header

[gielfeldt]

The specs allow for header paramters such as alg, jwk, jku, x5c, etc., which could have a determining factor in how the key is chosen.

This PR provides an interface for implementing such logic.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

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

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[gielfeldt]

@googlebot I signed it!

[google-cla]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[gielfeldt]

Signing agreements on open source pull requests ... I don't want to live on this planet anymore.

[google-cla]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[bshaffer]

@gielfeldt I understand your goal here now, and it seems like a good implementation.

I suppose my only real question is why users would need custom logic here, instead of us providing logic which chose the correct key by default based on the (as you said) alg, jwk, jku, x5c, etc.

[gielfeldt]

The abstraction proposed could still be used, and the library could just provide an implementation for choosing the key based on jku. I would also be necessary to validate/whitelist the jku. In my case, I only want to accept jwt sets from specific url(s).

…

Den 21. maj 2021 kl. 17.17 skrev Brent Shaffer ***@***.***>:  @gielfeldt I understand your goal here now, and it seems like a good implementation. I suppose my only real question is why users would need custom logic here, instead of us providing logic which chose the correct key by default based on the (as you said) alg, jwk, jku, x5c, etc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[bshaffer]

@gielfeldt Can you give me an example of what it looks like for the library to choose a key based on JKU? I believe the recommended way would be to fetch the JKU manually and pass them in as keys to JWT::decode.

[gielfeldt]

Passing to jwt::decode is too late, because we need the url specified in the header. (chicken/egg).

Another solution could be to expose some functionality to get the header from the token, before running the actual verification/decode process.

Some basic pseudo implementation:

class JkuBasedKey implements VerificationKeyInterface
{
    public function verificationKey(stdClass $header): string
    {

        // verify the url $header->jku is allowed

        // fetch jwk set from $header->jku

        // find $header->kid in jwk set

        // return appropriate key
    }
}

[bshaffer]

For this same use-case, I would rather do something like JWT::extractHeaderValue($jwt, 'jku'), or something along those lines.

I am worried the implementation here is too broad to be generally useful. A user could shoot themselves in the foot if the usage isn't very specific and well defined.

I am open to other ideas for how this can be implemented, but in general I'd rather have something very explicit, or keep it as-is where it's essentially not supported directly in this library.

[bshaffer]

Closing due to inactivity. Please open a feature request if anyone stumbles on this and wants either the solution in this PR or the one I suggested (JWT::extractHeaderValue)