-
Notifications
You must be signed in to change notification settings - Fork 68
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
Support encoding JWT using JWKS string #129
Comments
Thanks for writing this up @erhhung! I'm not familiar with JWK/JWKS, so this is a bit new for me. Taking an initial look, however, I don't think What are your thoughts? |
I would love to see this feature too. You don't need to generate keys before encoding first. You just need to require a JKW set that also contains the private key information. You can play with different JWK sets here https://mkjwk.org/ to get a better understanding of what that entails. As far as I can tell keats/jsonwebtoken has support for at least ES256 an ES384 these days. It might not be everything but some support is much better than no support. |
Unfortunately I don't have a lot of time to work on this at the moment (hence the delay here!) so if anyone would like to open a PR for this, I'd be happy to review! |
Summary
This is related to use cases described in both #119 and #128.
I'd like to run
jwt encode
by providing my own JWKS instead of a plaintext--secret
value. For example:where
MY_JWKS
can be retrieved from some HTTPS endpoint or generated locally using thejose
CLI:and
jwt-cli
would use the JWK in the provided keyset by matching the mandatory--kid
value.Besides just adding support for the JWKS standard, it allows using 256-bit (or whatever size) base64-encoded secrets that is in the JWKS
k
value. The--secret
parameter is currently unable to use a non-Unicode string value, throwing the following error if given a binary string:The text was updated successfully, but these errors were encountered: