You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a requirement to sign JWTs with a private key that is not accessible to the application runtime. The private key is held in a host key management service which does not expose the private key directly, but instead performs cryptographic functions on behalf of the application layer.
At the moment this library requires the application layer to have access to the private key so that the runtime can perform the cryptographic functions. It would be ideal if instead of requiring the key itself, it would be possible to provide a callable (or some other well defined type) which can perform the signing logic asynchronously.
A fairly low impact change could be to the sign method signatures to allow a callable which can return a promise with the signature payload:
// A callable that can perform the cryptographic signing in some wayinterfaceCustomSigner=(alg,data)=>Promise<Uint8Array>:
sign(keyOrSigner: CustomSigner|KeyLike|Uint8Array,options?: SignOptions): Promise<string>;
Under the hood I'd imagine a refactor being needed to wrap a KeyLike or Uint8Array into a callable (which contains the current implemented library logic) and then the code execution path would handle a callable.
I'm happy to author a fix for this if it's deemed to be of value. Of course all points raised here are up for discussion.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have a requirement to sign JWTs with a private key that is not accessible to the application runtime. The private key is held in a host key management service which does not expose the private key directly, but instead performs cryptographic functions on behalf of the application layer.
At the moment this library requires the application layer to have access to the private key so that the runtime can perform the cryptographic functions. It would be ideal if instead of requiring the key itself, it would be possible to provide a callable (or some other well defined type) which can perform the signing logic asynchronously.
A fairly low impact change could be to the
sign
method signatures to allow a callable which can return a promise with the signature payload:Under the hood I'd imagine a refactor being needed to wrap a
KeyLike
orUint8Array
into a callable (which contains the current implemented library logic) and then the code execution path would handle a callable.I'm happy to author a fix for this if it's deemed to be of value. Of course all points raised here are up for discussion.
Beta Was this translation helpful? Give feedback.
All reactions