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`.
When .verify() a corrupted JWS (e.g.: malicious user add extra characters in the middle of token) an error is thrown:
``
[ERROR] console - SyntaxError: Unexpected token ͧ
at Object.parse (native)
at Object.jwsDecode [as decode] (/www/socketio-jwt/node_modules/jsonwebtoken/node_modules/jws/lib/verify-stream.js:71:20)
at Object.module.exports.verify (/www/socketio-jwt/node_modules/jsonwebtoken/index.js:120:26)`
``
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' ]`.