[EdgarJ16]

Description

jwt.verify() validates the type of only four of the thirteen options it reads (clockTimestamp, nonce, maxAge and allowInvalidAsymmetricKeyTypes). jwt.sign(), by contrast, validates its options against a schema. As a result, a misconfigured verify() call can silently disable the expiration check.

Reproduction on v9.0.3 (commit b924272), with a token that expired 60 seconds ago:

jwt.verify(expiredToken, 'secret', { clockTolerance: 'abc' });        // returns the payload
jwt.verify(expiredToken, 'secret', { clockTolerance: '3600' });       // returns the payload
jwt.verify(expiredToken, 'secret', { clockTolerance: Infinity });     // returns the payload
jwt.verify(expiredToken, 'secret', { ignoreExpiration: 'false' });    // returns the payload

All four calls should throw TokenExpiredError. A string such as 'false' (for example, read from an environment variable) is truthy, so the expiration check is skipped. clockTolerance values that are not finite numbers make the comparison clockTimestamp >= exp + clockTolerance evaluate to false, so the token never expires.

This PR adds the missing validation at the top of verify(), next to the existing option checks and before the token is processed:

• HU-01: clockTolerance must be a finite number, otherwise JsonWebTokenError: clockTolerance must be a finite number.
• HU-02: ignoreExpiration and ignoreNotBefore must be booleans when defined, otherwise JsonWebTokenError: <option> must be a boolean.

Errors are returned through the callback when one is given, and thrown otherwise, consistent with the existing option validations.

Breaking changes. This is a behavior change for callers that pass invalid values today:

• Non-numeric, NaN, ±Infinity and null values for clockTolerance are now rejected. Before, null behaved like 0.
• Non-boolean values for ignoreExpiration and ignoreNotBefore (such as 0, 1, 'true', {}) are now rejected. Valid callers (true, false or the option omitted) are unaffected.

Alternatives considered. Coercing the values (for example 'false' to false) was rejected because it would hide the configuration error instead of reporting it. Moving all validation to a schema like sign() uses is a larger refactor and is left out of this PR.

Out of scope. Rejecting unknown option names (for example the typo algoritms) is tracked as a separate change (HU-03). The test file already includes its 3 test cases, which still fail in this PR on purpose.

References

• Baseline analysis of the library: jsonwebtoken v9.0.3 quality evaluation (PSWE-06, Universidad Cenfotec).
• Related behavior in sign(): sign_options_schema in sign.js.

Testing

New file: test/verify-options-validation.test.js (27 cases), written before the implementation and run first to confirm it failed (24 failing, 3 passing).