nbf + clockTolerance cause issues

https://github.com/auth0/node-jsonwebtoken/blob/73c4a5ac45d557ef0dc1c43fcae6b7fc9bc3f19e/verify.js#L116

The clockTolerance may be wrong when used together with nbf. When the token has just been issued if added with clockTolerance it’ll always fail I guess.

I’m pretty sure it should extend exp (expiration) time and shorten nbf (not before) time.

I can submit a PR if someone agrees.

[macedd]

I agree with @MitMaro as after reviewing the code again I could figure the logic was fine.

Still I could only get rid of the issues with tokens failing on another server (right after its creation) disabling the nbf completelly

jwt({ignoreNotBefore: true});

[ziluvatar]

I have this scenario currently when my frontend regenerates the token on failure, to sequentially try the same api endpoint again. node-jsonwebtoken is failing due to the clockTolerance.

Let me write the cases I can think of:

A) Clock timestamp => Frontend: 995 and API: 1000. Clock Tolerance: 10 Check: nbf=995 > clockTimestamp=1000 + clockTolerance=10 => false, all good Since the verifier is “in the future” from the signer point of view there will be never a fail here.

B) Clock timestamp => Frontend: 1000 and API: 995. Clock Tolerance: 10 Check: nbf=1000 > clockTimestamp=995 + clockTolerance=10 => false, all good Since the verifier is “in the past” from the signer point of view here the tolerance matters, it needs to be well defined.

B.2) Clock timestamp => Frontend: 1000 and API: 985. Clock Tolerance: 10 Check: nbf=1000 > clockTimestamp=985 + clockTolerance=10 => true, failure. Clock tolerance should be greater.

C) Clock timestamp => Frontend: 1000 and API: 1000. Clock Tolerance: 10 Check: nbf=1000 > clockTimestamp=1000 + clockTolerance=10 => false, all good

Can you think in any other? Did I miss anything?