validateJWT rejects Non-Integer iat, exp, nbf

[CS-Birb]

Describe the bug
validateJWT checks if provided iat, nbf and exp claims are Integers, and will throw exceptions if not. Naturally this will cause issues if an identity provider returns a JWT with floating-point NumericDates.

This behaviour appears to be counter to RFC7519, which defines NumericDates as so:

NumericDate

A JSON numeric value representing the number of seconds from
1970-01-01T00:00:00Z UTC until the specified UTC date/time,
ignoring leap seconds. This is equivalent to the IEEE Std 1003.1,
2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in
which each day is accounted for by exactly 86400 seconds, other
than that non-integer values can be represented. See RFC 3339
[RFC3339] for details regarding date/times in general and UTC in
particular.

To Reproduce
Steps to reproduce the behaviour:

1. Use a auth workflow that returns JWTs with Non-integer NumericDates (I.e. Jetbrains Hub)

Expected behaviour
Non-Integer NumericDate values to be considered valid

Environment:

• openid-client version: v3.15.0
• node version: v10.15.3

Additional context
The current behaviour may also be undesired for the auth_time claim. The OpenID Specs use the same language to define the type as with iat and exp

Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time.

• the bug is happening on latest openid-client too.
• i have searched the issues tracker on github for similar issues and couldn't find anything related.

[panva]

@CS-Birb thanks for bringing it up, it is fixed in v3.15.2