perf: Allow secret and publicKey options to be crypto.KeyObject (2x to 50x faster calls)#1971
Merged
kamilmysliwiec merged 1 commit intonestjs:masterfrom Oct 10, 2025
Conversation
When JwtService is initialized with `publicKey` as a string or Buffer, `verify()` and `verifyAsync()` pass it to "jsonwebtoken.verify()", which creates an instance of `crypto.KeyObject` from it via `crypto.createPublicKey()`. This is not free. Initializing `publicKey` with a `KeyObject` avoids this transformation in "jsonwebtoken". On my laptop, it makes `verify` twice faster. The same goes for `secret`, used in `sign()`, `verify()` and their asynchronous variants. Initializing with a `KeyObject` (built via `crypto.createSecretKey`) makes these functions ~50 times faster. See also auth0/node-jsonwebtoken@966.
micalevisk
reviewed
Jun 25, 2025
| signOptions?: jwt.SignOptions; | ||
| secret?: string | Buffer; | ||
| publicKey?: string | Buffer; | ||
| secret?: jwt.Secret; |
Member
There was a problem hiding this comment.
are you sure that we can still assign string or Buffer to these jwt.Secret fields? I didn't check the types nor the test suite
Contributor
Author
There was a problem hiding this comment.
Yes, we can use string or Buffer. See README of jsonwebtoken and code (here for example).
Tests in @nestjs/jwt already made sure that we can use a Buffer. No (non-mocked) tests used strings. I did not change that part.
micalevisk
approved these changes
Jun 29, 2025
|
Nice catch! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Current and new behaviors
When JwtService is initialized with
publicKeyas a string or Buffer,verify()andverifyAsync()pass it to "jsonwebtoken.verify()", which creates an instance ofcrypto.KeyObjectfrom it viacrypto.createPublicKey(). This is not free. InitializingpublicKeywith aKeyObjectavoids this transformation in "jsonwebtoken". On my laptop, it makesverifytwice faster.The same goes for
secret, used insign(),verify()and their asynchronous variants. Initializing with aKeyObject(built viacrypto.createSecretKey) makes these functions ~50 times faster.See also auth0/node-jsonwebtoken#966, which reports similar gains.
Does this PR introduce a breaking change?
Other information
I tentatively updated the README. Suggestions are most welcome! :) (Note that this README links to
jsonwebtokenown README, which has yet to be updated (see aforementioned issue).).