Precision of validation-timestamp

[kronthto]

The default timestamp uses time() which just has second precision.
Some OAuth-Servers/Providers - like Laravels passport (with thephpleague-server and Carbon2) / lcobucci - issue tokens with microsecond precision in the iat/nbf fields.
If such a token is validated with this lib in standard-configuration the same second (of course after) it is issued, validation will wrongly fail with the Cannot handle token prior to error (without systemclock skew), as $payload->iat > ($timestamp ) e.g. 1676279484.234102 > 1676279484 albeit the time of validation is e.g. 1676279484.7 or 1676279484.4 .

This can be mitigated by setting a $leeway of 1 second of course.
I think however the validation should be enhanced by either rounding or using a microtime()-stamp.

https://github.com/firebase/php-jwt/blob/4dd1e007f22a927ac77da5a3fbb067b42d3bc224/src/JWT.php#L96

Edit: May also apply to the nbf check - which is often also set to the issuance date

[RRosalia]

Yes experiencing exactly the same issue when trying to decode Laravel passport tokens.

[Krisell]

Related to #475 which discusses the strict check of iat that is not required by the JWT spec.

I suggest you (1) use the leeway to solve the issue, and (2) make a PR to this repository to either disable the strict iat check or add the rounding you suggest (the rounding might be releasable in a patch version).

[croensch]

Talking about precision, for me this raises an:

ErrorException(code: 0): Deprecated: Implicit conversion from float 1677835376.492769 to int loses precision at /application/vendor/firebase/php-jwt/src/JWT.php:156

Because \date(DateTime::ISO8601, $payload->iat) does not accept float but integer.

[yash30201]

Closing this issue as the interim solution for this has already been merged and released in #492 .

Usage of microtime instead of time has been delayed for a major version release as explained in #523 .