Update dependency jsonwebtoken to v9#3
Open
dev-mend-for-github-com[bot] wants to merge 1 commit intomasterfrom
Open
Update dependency jsonwebtoken to v9#3dev-mend-for-github-com[bot] wants to merge 1 commit intomasterfrom
dev-mend-for-github-com[bot] wants to merge 1 commit intomasterfrom
Conversation
98c6b50 to
425ea83
Compare
4cedde6 to
425ea83
Compare
7ed9b7b to
425ea83
Compare
425ea83 to
5c4e9fb
Compare
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
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.
This PR contains the following updates:
0.4.0→9.0.0By merging this PR, the below vulnerabilities will be automatically resolved:
Release Notes
auth0/node-jsonwebtoken (jsonwebtoken)
v9.0.0Compare Source
Breaking changes: See Migration from v8 to v9
Breaking changes
8345030]8345030)ecdf6cc]ecdf6cc)Security fixes
Arbitrary File Write via verify function- CVE-2022-23529Insecure default algorithm in jwt.verify() could lead to signature validation bypass- CVE-2022-23540Insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC- CVE-2022-23541Unrestricted key type could lead to legacy keys usage- CVE-2022-23539v8.5.1Compare Source
Bug fix
Docs
v8.5.0Compare Source
New Functionality
Test Improvements
Docs
v8.4.0Compare Source
New Functionality
Bug Fixes
Docs
Test Improvements
CI
v8.3.0Compare Source
v8.2.2Compare Source
v8.2.1Compare Source
v8.2.0Compare Source
v8.1.1Compare Source
v8.1.0Compare Source
v8.0.1Compare Source
lodash.isarraydependency (#394) (7508e8957cb1c778f72fa9a363a7b135b3c9c36d)v8.0.0Compare Source
Breaking changes: See Migration notes from v7
v7.4.3Compare Source
v7.4.2Compare Source
v7.4.1Compare Source
v7.4.0Compare Source
v7.3.0Compare Source
maxAgeoption in README (1b0592e99cc8def293eed177e2575fa7f1cf7aa5)clockTimestampoption toverify()you can set the current time in seconds with it (#274) (8fdc1504f4325e7003894ffea078da9cba5208d9)verify()input (#305) (1b6ec8d466504f58c5a6e2dae3360c828bad92fb), closes #305v7.2.1Compare Source
v7.2.0Compare Source
keyidonsign. (b412be91b89acb3a742bb609d3b54e47e1dfc441)v7.1.10Compare Source
v7.1.9Compare Source
v7.1.8Compare Source
v7.1.7Compare Source
v7.1.6Compare Source
v7.1.5Compare Source
v7.1.3Compare Source
v7.1.1Compare Source
v7.1.0Compare Source
v7.0.1Compare Source
v7.0.0Compare Source
v6.2.0Compare Source
options.clockTolerancetojwt.verify(65ddea934f226bf06bc9d6a55be9587515cfc38d)v6.1.2Compare Source
v6.1.1Compare Source
v6.1.0Compare Source
v6.0.1Compare Source
This was an immediate change after publishing 6.0.0.
v6.0.0Compare Source
Change .sign to standard async callback (50873c7d45d2733244d5da8afef3d1872e657a60)
Improved the options for the
signmethod (53c3987b3cc34e95eb396b26fc9b051276e2f6f9)expiresInwhen the payload is not an object (304f1b33075f79ed66f784e27dc4f5307aa39e27)expiresInMinutesandexpiresInSecondsare deprecated and no longer supported.notBeforeInMinutesandnotBeforeInSecondsare deprecated and no longer supported.optionsare strongly validated.options.expiresIn,options.notBefore,options.audience,options.issuer,options.subjectandoptions.jwtidare mutually exclusive withpayload.exp,payload.nbf,payload.aud,payload.issoptions.algorithmis properly validated.options.headersis renamed tooptions.header.update CHANGELOG to reflect most of the changes. closes #136 (b87a1a8d2e2533fbfab518765a54f00077918eb7), closes #136
update readme (53a88ecf4494e30e1d62a1cf3cc354650349f486)
v5.7.0Compare Source
v5.6.2Compare Source
v5.6.0Compare Source
v5.5.4Compare Source
v5.5.3Compare Source
v5.5.2Compare Source
v5.5.1Compare Source
v5.5.0Compare Source
v5.4.1Compare Source
v5.4.0Compare Source
v5.3.1Compare Source
v5.2.0Compare Source
v5.1.0Compare Source
v5.0.5Compare Source
v5.0.4Compare Source
v5.0.3Compare Source
thisreferring to the global object instead ofmodule.exportsinverify()(93f554312e37129027fcf4916f48cb8d1b53588c)v5.0.2Compare Source
v5.0.1Compare Source
v5.0.0Compare Source
Changed
iatif the user does not specify that argument.e90028235036b1954bd7a24a3700a77df6dSecurity
header.algmismatch exception toinvalid algorithmand adding more mismatch tests.As
jws@3.0.0changed the verify method signature to bejws.verify(signature, algorithm, secretOrKey), the token header must be decoded first in order to make sure that thealgfield matches one of the allowedoptions.algorithms. After that, the now validatedheader.algis passed tojws.verifyAs the order of steps has changed, the error that was thrown when the JWT was invalid is no longer the
jwsone:That old error (removed from jws) has been replaced by a
JsonWebTokenErrorwith messageinvalid token.634b8ed9f24ffd19e6cc61e46234954bd7a24a3700a77df6dv4.2.2Compare Source
Fixed
jfromaniello - awlayton)40279468df6aabv4.2.1Compare Source
Fixed
jfromaniello)7017e74v4.2.0Compare Source
Security
When the verification part was expecting a token digitally signed with an asymmetric key (RS/ES family) of algorithms an attacker could send a token signed with a symmetric algorithm (HS* family).
The issue was caused because the same signature was used to verify both type of tokens (
verifymethod parameter:secretOrPublicKey).This change adds a new parameter to the verify called
algorithms. This can be used to specify a list of supported algorithms, but the default value depends on the secret used: if the secretOrPublicKey contains the stringBEGIN CERTIFICATEthe default is[ 'RS256','RS384','RS512','ES256','ES384','ES512' ]otherwise is[ 'HS256','HS384','HS512' ]. (jfromaniello)