Enable integration with third-party signing

[fredericgboutin-yapla]

Following #93 (comment)

Damn, @Ocramius got upset quick I couldn't even answer @SvenRtbg

Reviving an issue created and closed in 2016, targeting a version that isn't valid today, is kinda "meh".

If you see the issue as a feature request, I don't see what's the problem if it is an old thread or a new one, from a project management perspective it is still valid to me - aka using a cloud service like AWS for managing asymmetric keys involves NOT having access to the private key by definition but only an API.

But anyways: We have the Signer interface:

I know, I read the thread 😅

What exactly is missing that could be considered general-purpose (as to warrant implementing this here instead of a separate add-on library) that you would need for any cloud operation?

Like I said, I can do it myself and sure enough we already use the AWS Client library, there is no problem here except that it seems to me that this is a generic problem with a generic solution.

I searched on packagist so maybe there is a library extending lcobucci/jwt but no.

So basically, since we probably have to develop a custom unit-tested AWS KMS Signer for lcobucci/jwt, what option is best?

1. we create our own independent project with an explicit dependency on lcobucci/jwt
2. we submit a pull request providing a new Signer and lcobucci/jwt adds an OPTIONAL dependency on aws/aws-sdk-php

Or else?

We still have some projects stuck on v4 because of PHP 7.4 so we'll most probably need to backport it.

What's your vibe on this?

[Ocramius]

2. we submit a pull request providing a new Signer and lcobucci/jwt adds an OPTIONAL dependency on aws/aws-sdk-php

This won't fly anyway: dependencies are there, or aren't 😁

Optional dependencies are not really a thing: they are crashes waiting to happen.

I suggest you first implement it privately in your project, then consider publishing a package if it works for you first.

[Ocramius]

Damn, @Ocramius got upset quick I couldn't even answer @SvenRtbg

Not upset: I just try and keep convos tidy: it's perfectly fine to discuss here 👍

[SvenRtbg]

Allow my 0,02€ here:

AWS signing a JWT probably is a generic problem - in the Amazon cloud environment. It's not for users of Microsoft's or Googles cloud, and it probably would not make sense to attach all three cloud providers client libraries here just to provide a multi-generic solution.

And I also want to emphasize that there is no such thing as an optional dependency. From maintainer perspective, it is quite a pain to maintain, and from consumers perspective, it is, as Ocramius briefly said, a crash waiting to happen: The dependency is only suggested, no specific version is requested, either forgetting to install it or running into version conflicts with that package already installed in the wrong version, can only be found out during runtime. Which hopefully would be unit test time if you are smart enough to write the correct tests, but might easily be production run time if enough bad decisions are in place.

[fredericgboutin-yapla]

I wasn't aware optional deps with composer was such a massive pain.

• https://github.com/alexander-schranz/composer-optional-dependencies?tab=readme-ov-file#what-does-composer-say-about-optional-dependencies
• [RFC] Optional dependencies composer/composer#11635

I'm taking notes. Thanks!

[SvenRtbg]

You found a nice source there, thanks! And this issue isn't only Composer or PHP, it is all languages and their dependency management systems. The only difference might be some are more used to that bad habit and allow it more.

[fredericgboutin-yapla]

I just started implementing it yesterday and I think it goes in the direction of a dedicated package. Like @SvenRtbg is saying, it is probably more specific to AWS itself, even though that support is generic.

We got a PoC working based on ECDSA SHA 256 - aka ES256 - after struggling with the DER-encoded signature - see https://docs.aws.amazon.com/aws-sdk-php/v3/api/api-kms-2014-11-01.html#sign.

We came to realize we probably just need to observe the same pattern as the classes in the Lcobucci\JWT\Signer\Ecdsa namespace so we directly inherit from Ecdsa implementation which properly convert DER-encoded signature with a call to fromAsn1().

[lcobucci]

That sounds like a good direction to take, you might need to apply some base64 decoding if aws' lib doesn't give you binary content.

If you decide to open source that package, feel free to send a PR to our docs linking to it 👍

[fredericgboutin-yapla]

Thanks for the heads up.

As per the AWS doc,

When you use the HTTP API or the Amazon Web Services CLI, the value is Base64-encoded. Otherwise, it is not Base64-encoded.

The wording is a bit confusing, but it means that using the Aws Client in PHP the returned signature is NOT Base64-encoded, and I confirm that since I can properly decode the DER-encoded object.