* Corrected indistinguishable error messages
jws.decode() never throws an error. At least, in its current version. However, if it were to throw an exception, the diagnostics would be indistinguishable from a soft failure to decode a token. I had an extra trailing space on my JWT and it took me some additional debugging work to trace the actual root cause because the error message was not distinct.
* Allowed an exception from inside of jws.decode to be handled by the caller. Currently, jws.decode never throws an exception. The change is made per discsussion in the original PR
* Added a test case and proper forwarding of the possible exception thrown from jws.decode
* Typo correction
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.