Notable changes:
1. `expiresInMinutes` and `expiresInSeconds` are deprecated and no longer supported.
2. `notBeforeInMinutes` and `notBeforeInSeconds` are deprecated and no longer supported.
3. options are properly validated.
4. `options.expiresIn`, `options.notBefore`, `options.audience`, `options.issuer`, `options.subject` and `options.jwtid` are mutually exclusive with `payload.exp`, `payload.nbf`, `payload.aud`, `payload.iss`, `payload.sub` and `payload.jti` respectively.
5. `options.algorithm` is properly validated.
6. `options.headers` is renamed to `options.header`.
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.
José F. Romaniello