'Google Client Invalid JWT: Token must be a short-lived token

I am using Google's php api client. I am running through the quickstart guide for service accounts. I followed the steps perfectly (as far as I can tell). I am running into the following error:

{
   "error": "invalid_grant",
   "error_description": "Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values and use a clock with skew to account for clock differences between systems."
}

From what I have read the most common problem with this error is if the system time is wrong. I have triple checked that my timezone and date and time are synced with the atomic clock. I used php set timezone function to set my timezone to match my computer, but I continue to get the error. I am looking into the other part of the message that mentions the iat and exp settings, and haven't gotten anywhere yet.

Does anyone have any ideas of how I can get past this?

phpgoogle-apigoogle-api-php-client


Solution 1:[1]

Invalid_grant error has two common causes:

  1. Your server’s clock is not in sync with NTP.

    Solution: Check the server time. If it's incorrect, fix it.

  2. The refresh token limit has been exceeded.

    Solution: Nothing you can do - they can't have more refresh tokens in use.

    Applications can request multiple refresh tokens. For example, this is useful in situations where a user wants to install an application on multiple machines. In this case, two refresh tokens are required, one for each installation. When the number of refresh tokens exceeds the limit, older tokens become invalid. If the application attempts to use an invalidated refresh token, an invalid_grant error response is returned.

    The limit for each unique pair of OAuth 2.0 client and is 50 refresh tokens (note that this limit is subject to change). If the application continues to request refresh tokens for the same Client/Account pair, once the 26th token is issued, the 1st refresh token that was previously issued will become invalid. The 27th requested refresh token would invalidate the 2nd previously issued token and so on.

Solution 2:[2]

Fixed the issue for me in 2020.

  • If on Windows, right click the date and time on the lower right.
  • Click "Adjust Date/Time".
  • Click "Sync now."

Solution 3:[3]

WOW!!! This ended up being something really stupid. I am running Laravel's homestead as my dev server. I mostly assumed that the clocks on my VM and local machine would be synced. At least at the time of creation. But, I went a couple weeks without using this machine, so (I'm guessing), the VMs clock wasn't running while this computer was in hibernation, or the clocks were never in sync. Regardless, the issue is that my vm's clock was about 9 days behind my system clock. That was causing the issue.

Solution 4:[4]

if you run localy, check the time zone of your computer, for me it was the problem, the best solution in this case is to set it to automatic

Solution 5:[5]

Check your system time once. It may happen that you have dual boot because of which Windows couldn't update the latest timezone. Just refresh it once again in settings and see the magic.

Don't know why that dependency but that's how it is!

Solution 6:[6]

In Linux, I solved this problem by selecting the automatic date and time option.

Solution 7:[7]

In MacOs Catalina (10.15.7), I solved this problem by selecting the automatic date and time option.

Solution 8:[8]

For my case, I just need to restart my machine. (Faced the issue on vagrant VM). It's working again.

Solution 9:[9]

I found a solution by changing the time zone to that of the server:

date
Output:
Wed Apr 26 17:44:38 UTC 2017

and then:

timedatectl list-timezones
sudo timedatectl set-timezone America/New_York
Output:
Wed Apr 26 13:55:45 EDT 2017

Solution 10:[10]

First I doubted about changing server time. Because it's only 5 minutes differences between server and my computer(network time). I've been looking for various methods related to oAuth, but I have changed the server time in case, and it works well amazingly.

Solution 11:[11]

I had this with WSL2 on Windows - sometimes when the laptop hibernates, the WSL time falls behind the system time.

Run sudo hwclock -s to sync.

Related Questions