fix(deps): update dependency jsonwebtoken to v9 [security] (#1112)

[![Mend
Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)

This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [jsonwebtoken](https://togithub.com/auth0/node-jsonwebtoken) |
[`^8.5.1` ->
`^9.0.0`](https://renovatebot.com/diffs/npm/jsonwebtoken/8.5.1/9.0.0) |
[![age](https://badges.renovateapi.com/packages/npm/jsonwebtoken/9.0.0/age-slim)](https://docs.renovatebot.com/merge-confidence/)
|
[![adoption](https://badges.renovateapi.com/packages/npm/jsonwebtoken/9.0.0/adoption-slim)](https://docs.renovatebot.com/merge-confidence/)
|
[![passing](https://badges.renovateapi.com/packages/npm/jsonwebtoken/9.0.0/compatibility-slim/8.5.1)](https://docs.renovatebot.com/merge-confidence/)
|
[![confidence](https://badges.renovateapi.com/packages/npm/jsonwebtoken/9.0.0/confidence-slim/8.5.1)](https://docs.renovatebot.com/merge-confidence/)
|

### GitHub Vulnerability Alerts

####
[CVE-2022-23539](https://togithub.com/auth0/node-jsonwebtoken/security/advisories/GHSA-8cf7-32gw-wr33)

# Overview

Versions `<=8.5.1` of `jsonwebtoken` library could be misconfigured so
that legacy, insecure key types are used for signature verification. For
example, DSA keys could be used with the RS256 algorithm.

# Am I affected?

You are affected if you are using an algorithm and a key type other than
the combinations mentioned below

| Key type |  algorithm                                    |
|----------|------------------------------------------|
| ec           | ES256, ES384, ES512                      |
| rsa          | RS256, RS384, RS512, PS256, PS384, PS512 |
| rsa-pss  | PS256, PS384, PS512                      |

And for Elliptic Curve algorithms:

| `alg` | Curve      |
|-------|------------|
| ES256 | prime256v1 |
| ES384 | secp384r1  |
| ES512 | secp521r1  |

# How do I fix it?

Update to version 9.0.0. This version validates for asymmetric key type
and algorithm combinations. Please refer to the above mentioned
algorithm / key type combinations for the valid secure configuration.
After updating to version 9.0.0, If you still intend to continue with
signing or verifying tokens using invalid key type/algorithm value
combinations, you’ll need to set the `allowInvalidAsymmetricKeyTypes`
option to `true` in the `sign()` and/or `verify()` functions.

# Will the fix impact my users?

There will be no impact, if you update to version 9.0.0 and you already
use a valid secure combination of key type and algorithm. Otherwise, use
the `allowInvalidAsymmetricKeyTypes` option to `true` in the `sign()`
and `verify()` functions to continue usage of invalid key type/algorithm
combination in 9.0.0 for legacy compatibility.

####
[CVE-2022-23541](https://togithub.com/auth0/node-jsonwebtoken/security/advisories/GHSA-hjrf-2m68-5959)

# Overview

Versions `<=8.5.1` of `jsonwebtoken` library can be misconfigured so
that passing a poorly implemented key retrieval function (referring to
the `secretOrPublicKey` argument from the [readme
link](https://togithub.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback))
will result in incorrect verification of tokens. There is a possibility
of using a different algorithm and key combination in verification than
the one that was used to sign the tokens. Specifically, tokens signed
with an asymmetric public key could be verified with a symmetric HS256
algorithm. This can lead to successful validation of forged tokens.

# Am I affected?

You will be affected if your application is supporting usage of both
symmetric key and asymmetric key in jwt.verify() implementation with the
same key retrieval function.

# How do I fix it?
 
Update to version 9.0.0.

# Will the fix impact my users?

There is no impact for end users

####
[CVE-2022-23540](https://togithub.com/auth0/node-jsonwebtoken/security/advisories/GHSA-qwph-4952-7xr6)

# Overview

In versions <=8.5.1 of jsonwebtoken library, lack of algorithm
definition and a falsy secret or key in the `jwt.verify()` function can
lead to signature validation bypass due to defaulting to the `none`
algorithm for signature verification.

# Am I affected?
You will be affected if all the following are true in the `jwt.verify()`
function:
- a token with no signature is received
- no algorithms are specified 
- a falsy (e.g. null, false, undefined) secret or key is passed 

# How do I fix it?
 
Update to version 9.0.0 which removes the default support for the none
algorithm in the `jwt.verify()` method.

# Will the fix impact my users?

There will be no impact, if you update to version 9.0.0 and you don’t
need to allow for the `none` algorithm. If you need 'none' algorithm,
you have to explicitly specify that in `jwt.verify()` options.

---

### Release Notes

<details>
<summary>auth0/node-jsonwebtoken</summary>

###
[`v9.0.0`](https://togithub.com/auth0/node-jsonwebtoken/blob/HEAD/CHANGELOG.md#&#8203;900---2022-12-21)

[Compare
Source](https://togithub.com/auth0/node-jsonwebtoken/compare/v8.5.1...v9.0.0)

**Breaking changes: See [Migration from v8 to
v9](https://togithub.com/auth0/node-jsonwebtoken/wiki/Migration-Notes:-v8-to-v9)**

##### Breaking changes

-   Removed support for Node versions 11 and below.
- The verify() function no longer accepts unsigned tokens by default.
(\[[`8345030`](https://togithub.com/auth0/node-jsonwebtoken/commit/834503079514b72264fd13023a3b8d648afd6a16)]https://github.com/auth0/node-jsonwebtoken/commit/834503079514b72264fd13023a3b8d648afd6a16)
- RSA key size must be 2048 bits or greater.
(\[[`ecdf6cc`](https://togithub.com/auth0/node-jsonwebtoken/commit/ecdf6cc6073ea13a7e71df5fad043550f08d0fa6)]https://github.com/auth0/node-jsonwebtoken/commit/ecdf6cc6073ea13a7e71df5fad043550f08d0fa6)
-   Key types must be valid for the signing / verification algorithm

##### Security fixes

- security: fixes `Arbitrary File Write via verify function` -
CVE-2022-23529
- security: fixes `Insecure default algorithm in jwt.verify() could lead
to signature validation bypass` - CVE-2022-23540
- security: fixes `Insecure implementation of key retrieval function
could lead to Forgeable Public/Private Tokens from RSA to HMAC` -
CVE-2022-23541
- security: fixes `Unrestricted key type could lead to legacy keys
usage` - CVE-2022-23539

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "" (UTC), Automerge - At any time (no
schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/quirrel-dev/quirrel).

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNC42Ni4xIiwidXBkYXRlZEluVmVyIjoiMzUuMTMxLjAiLCJ0YXJnZXRCcmFuY2giOiJtYWluIn0=-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Author: renovate[bot]

package-lock.json

@@ -99,7 +99,7 @@
     "ioredis-mock": "^8.2.2",
     "ipaddr.js": "^2.0.1",
     "js-yaml": "^4.1.0",
-    "jsonwebtoken": "^8.5.1",
+    "jsonwebtoken": "^9.0.0",
     "ms": "2.1.3",
     "node-fetch": "2.6.7",
     "open": "8.4.0",