As `[email protected]` changed the verify method signature to be `jws.verify(signature, algorithm, secretOrKey)`, the token header must be decoded first in order to make sure that the `alg` field matches one of the allowed `options.algorithms`. After that, the now validated `header.alg` is passed to `jws.verify`
As the order of steps has changed, the error that was thrown when the JWT was invalid is no longer the `jws` one:
{ [Error: Invalid token: no header in signature 'a.b.c'] code: 'MISSING_HEADER', signature: 'a.b.c' }
That old error (removed from jws) has been replaced by a `JsonWebTokenError` with message `invalid token`. That's why this change will bump be a major.
There is a vulnerability in this module when the verification part is expecting a token digitally signed with an asymetric key (RS/ES family) of algorithms but instead the attacker send a token digitally signed with a symmetric algorithm (HS* family).
The issue is because this library has the very same signature to verify both type of tokens (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 string `BEGIN CERTIFICATE` the default is `[ 'RS256','RS384','RS512','ES256','ES384','ES512' ]` otherwise is `[ 'HS256','HS384','HS512' ]`.
draft-ietf-oauth-json-web-token does not require JWT objects to have typ: "JWT"
in their header. Yet it expects that the JWT's claim set be JSON for validation.
See step 10 of draft-ietf-oauth-json-web-token section 7.2 "Validating a JWT".
Prior to this commit JWTs without typ: "JWT" in header are validated without
ever checking the claim set.
The message part of the JsonWebTokenError generated for aud and iss mismatch
currently use the [PAYLOAD AUDIENCE] and [PAYLOAD ISSUER] as the expected value.
This leads to confusion. For example, say a JWT aud is set to
'https://localhost' and the expected value is 'https://localhost:8443'. The
resulting error message is:
'jwt audience invalid. expected: https://localhost:8443'
Which of courses tells the user that the audience is incorrect, yet the expected
value is the value sent.
This commit changes the error message to use the actual expected values,
[OPTIONS AUDIENCE] and [OPTIONS ISSUER].
Alberto Pose