-
-
Notifications
You must be signed in to change notification settings - Fork 592
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable integration with third-party signing #93
Comments
@udf2457 so all we need to do is change the Key class to accept a string that you can generate yourself ? |
@geggleto Sounds about right. (I'm guessing the function to retrieve payload/string to sign is already marked public, if not it will need to be). |
As you can see on https://github.com/lcobucci/jwt/blob/3.1/src/Signer/Key.php#L45 we already allow strings on constructors, so you can do the "black-box" magic and create a new The |
For branch 2.1if you look at... https://github.com/lcobucci/jwt/blob/2.1/src/Builder.php#L213-L223 Same thing for verifying... |
@geggleto v2 was discontinued and should not be used due to security reasons. |
@lcobucci ah okay, noted. |
@lcobucci Am a little confused about your reference to https://github.com/lcobucci/jwt/blob/3.1/src/Signer/Key.php#L45, isn't that used for providing a Key not a signed string ? |
@udf2457 if your Content does not contain the string |
@udf2457 exactly as @geggleto explained 😉 // You can create:
$key = new Key('file:///test/private_key.pem');
// or:
$key = new Key(file_get_contents('/test/private_key.pem'));
// or: (with the right line endings)
$key = new Key('-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQDdlatRjRjogo3Wojg...'); If you need more power you could even do: final class KeyVaultObject
{
public function __toString():string
{
// Your black magic here
return 'black magic result';
}
}
$key = new Key(new KeyVaultObject('identifier')); |
@geggleto @lcobucci So, just to be sure, based on the example code on your homepage that this sort of thing will work as intended ?
|
Yes, but surely this is exactly the problem I'm telling you ? ;-) The cloudy stuff is HSM.... i.e. once in the HSM, the private key never emerges. You can only ever ask it to "sign,decrypt,verify,encrypt" .... the private key stays locked-up inside the HSM at all times, the only key you can view is the public key. |
I ended up writing my own wrapper around it... https://github.com/geggleto/securejwt required libsodium tho |
Alright, this is getting silly now. I've got nothing against the great libsodium, but surely I don't need it to be able to concatenate a ready-made signature onto a JWT token (I'm no JWT guru but I'm guessing that's how it works !) |
@udf2457 ok so your problem is not about with the For that you just need to implement the I have no intention on providing customized signers in this package but you can create one that has this lib as dependency and adds a HSM signer (which can be useful to others). I'll gladly put your package as suggestion of this lib. |
@lcobucci ok, I'll take a look at the interfaces suggested. |
@udf2457 don't forget to use the stable version as dependency as |
Will mark this as |
Does anyone have a solution to this particular issue? I am currently in the same situation. |
@omitobi delegating the signing process to an external component can be achieved by implementing a custom algorithm (signer): https://lcobucci-jwt.readthedocs.io/en/stable/extending-the-library/#signer If this doesn't clarify it enough, please open a discussion (not issue) asking a more detailed question 👍 |
I mean, @omitobi is kind of right. The original issue is still valid: Enable integration with third-party signing Yes, there is a workaround so you can hack you way. But I'm in a situation were I would like to leverage AWS KMS. Obviously I would have preferred if someone else had already developed and tested that support. The point is, |
Reviving an issue created and closed in 2016, targeting a version that isn't valid today, is kinda "meh". But anyways: We have the
We have the
We have the 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? Have you considered implementing a bit of glue code to utilize the |
What @SvenRtbg said: locking. |
For those people who may use cloud-based security infrastructure (e.g. Azure Keyvault HSM, Amazon AWS HSM), there is no way to integrate signing with lcobucci/jwt because, for example, your code presently requires people to supply the path to the private key on the local filesystem.
For avoidance of doubt, I am not saying that you need to code all the API communications ! I am just saying, give me an easy way to (a) get the "string to sign" and (b) supply the signed value back to lcobucci/jwt .... the "black-box" magic in the middle can be done by people's code.
Hope this makes sense.
The text was updated successfully, but these errors were encountered: