I implemented a login functionality using Google Plus API. It was working fine until we moved the deployment timezone. The problem below started appearing from time to time even though the server time has been adjusted properly:
Cannot handle token prior to 2018-02-01T06:30:07+0000
This was implemented in PHP and using the SDK for Google Plus. Has anyone encountered this before and resolved it properly?
23 Answers
This worked for me as well. I had to go into my vendor folder that composer generates for me in vendor\google\apiclient\src\Google\AccessToken\Verify.php and look for a function getJwtService() which should look exactly like this
private function getJwtService() { $jwtClass = 'JWT'; if (class_exists('\Firebase\JWT\JWT')) { $jwtClass = 'Firebase\JWT\JWT'; } if (property_exists($jwtClass, 'leeway')) { // adds 1 second to JWT leeway // @see $jwtClass::$leeway += 1; } return new $jwtClass; }Then I changed the value of the $jwtClass::$leeway += 1; to $jwtClass::$leeway += 200; due to my timezone. I was about 2mins 30 seconds behind. Beware this comes with security vulnerabilities.
While the answer provided by richard4s works well but it's not a good practice to edit files in vendor directory as they are created by composer and would typically be outside your project's Git/Svn repo. The Google_Client accepts custom jwt object as a parameter to it's constructor. So here's a proper way to fix this:
$jwt = new \Firebase\JWT\JWT;
$jwt::$leeway = 5; // adjust this value
// we explicitly pass jwt object whose leeway is set to 5
$this->client = new \Google_Client(['jwt' => $jwt]);Copied from this article.
This error appears to occur when the server's clock is a few seconds behind Auth servers clock. You probably have a slight skew between the clock on the server that mints the tokens and the clock on the server that's validating the token if the iat or nbf is in the future, then the token isn't yet valid.
One solution would be to use a small leeway, like this:
JWT::$leeway = 5; // Allows a 5 second tolerance on timing checks
see issue 1172
4