Token must be a short-lived token and in a reasonable timeframe

Viewed 40213

I am having the same error as this. In my case it is happening when the app is trying to upload a file via Google Cloud Client API.

POST https://www.googleapis.com/oauth2/v4/token
400 Bad Request
Invalid JWT: Token must be a short-lived token and in a reasonable timeframe

How I load the token is reading a service-account json file, and attach it to CURLOPT_HTTPHEADER in PHP. It did work properly for the past one month, so I am guessing that Google changed the way of authorization.

Has anyone faced & solved this?

10 Answers

For those getting that error for a containerized app and ending up here,

I had the same issue when using my token from a containerized app. Rebooting Docker Desktop (Windows) did it for me.

I had this setup for weeks before getting that issue for the first time.

For those using vagrant, ssh into your box and run sudo service ntp stop && sudo ntpd -gq && sudo service ntp

I had the similar problem and my job was keep failing with below error:

  File "/usr/local/lib/python2.7/site-packages/google/oauth2/_client.py", line 59, in _handle_error_response
    error_details, response_body)
google.auth.exceptions.RefreshError: ('invalid_grant: 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.', u'{\n  "error" : "invalid_grant",\n  "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."\n}')
2018-05-1713:01:01:  API CALL iOS intra day: module failed.

The actual root cause was the system time was out of sync with the server. I have refreshed the ntp server which synced the time and the problem was resolved.

I had a similar problem when trying to reach the google cloud big query API. Adjusting my system clock and allowing windows 10 to automatically set the time and time zone solved the problem.

I had this problem when using Windows Subsystem for Linux (WSL). All my WSL images were running with date set in the past, https://github.com/microsoft/WSL/issues/4245 suggests that its a problem when Windows resumes from sleep.

I fixed by restarting WSL, wsl --shutdown

It sounds obvious, but ensure the expiry exp is after the issued at time iat.

Related