lcobucci
Timezone error in apple login .
Is it possible to substract the leeway instead of adding it in https://github.com/lcobucci/jwt/blob/6.0.x/src/Validation/Constraint/LooseValidAt.php#L39
this fixes the problem described in https://github.com/SocialiteProviders/Providers/issues/1354
The problem occurs when the token is immediately verified after the generation.
Adding or substracting 0 seconds doesn't change the outcome.
The leeway parameter exists exactly for your use case, where clocks of different servers are not in sync: try to instantiate the LooseValidAt class with the leeway parameter until it matches your expectations:
new LooseValidAt(
SystemClock::fromSystemTimezone(),
new DateInterval('PT3S'), // <- Consider a 3 seconds differece between servers
),
Adding 35 seconds would trigger a "generated in the future" exception - since we ad before calling assertGeneratedBefore
The $leeway is validated to be a positive \DateInterval, and is used to
- add time to the current clock when validating the "issued at" timestamp - checking that the extended "now" timestamp is greater than the "iat" claim, making timestamps "from the past" valid. (there is a negation happening which I ignored, so in fact adding time to "now" makes token timestamps from the future valid)
- add time to the current clock when validating the "not before" timestamp - checking that the extended "now" timestamp is greater than the "nbf" claim, making timestamps "from the past" valid. (same as above)
- subtracts time of the current clock when validating the "expired" timestamp - checking that the reduced "now" timestamp is greater than the "exp" claim, making timestamps "from the future" still valid.
So all the "LooseValidAt" is doing is allowing to extend the time range where a token is considered valid, defined by the lower boundaries "iat" and "nbf" (the value most into the future), and the higher boundary "exp". If the issuer clock is out of sync, the leeway parameter allows to accept up to that much time difference.
Where is the "generated in the future" aspect coming from. Certainly nothing that was discussed previously. Please consider that nobody here wants to click through some code in another repo and guess what you might look at - be specific in this issue here and paste your code that you have an issue with. Makes it much easier, also for later readers who are redirected to the current master branch of the other repo and wonder what the commotion is all about, as the code looks fine (because it was changed to fix the issue).
@harrowmykel Do we all agree that the issue is not within lcobucci/jwt as of now, so it's warranted to close it? Feel free to reopen if that turns out to be wrong in the future.