invalid_grant on service Account for google API

[GoogleCodeExporter]

What steps will reproduce the problem?
1. downloading latest version (trunk) 
2. using setAssertionCredentials with service_account_name and keyfilecontent
3. adding service_account_name on personnal account on google analytics 
4. trying to get list of profile id and then 

What is the expected output? What do you see instead?
list of profile ids

What version of the product are you using? On what operating system?
trunk version (latest) on windows wamp

Please provide any additional information below.
web application works perfectly
need solution to access data from my own GA account 
method already created need only to make automatic connections 

Thank you

Original issue reported on code.google.com by mchenouili@gmail.com on 23 Jul 2012 at 9:21

[GoogleCodeExporter]

Sorry mistyped 
4. trying to get list of profile id and then invalid_grant error

Original comment by mchenouili@gmail.com on 23 Jul 2012 at 9:28

[GoogleCodeExporter]

Just a note that this was also an issue in the Python version of the API (which 
has already been fixed over there): 
http://code.google.com/p/google-api-python-client/issues/detail?id=168

It appears to be related to the fact that depending on your system clock time 
vs. the Google server clock time your request may appear to be coming from the 
future. Simply subtracting a few seconds from the timestamp appears to resolve 
the issue. 

Line 58 of apiAssertionCredentials.php currently looks like this:

$now = time();

Changing that to this:

$now = time() - 10;

Appears to have fixed this bug for me. This is obviously not a great solution 
to this problem, so it would be nice to have an official fix.

Original comment by raven...@gmail.com on 8 Aug 2012 at 3:30

[GoogleCodeExporter]

This issue is not limited to the PHP API - It seems like a server-side defect.
I'm having the same issue with v3.0 of the .NET library.
If the signing computer's clock is skewed, even by 1 second, into the future, 
the API call fails with "invalid_grant". Skewing the clock up to 60 minutes to 
the past, seems to work fine.

Checking the clock with digital signatures is a common practice, but a clock 
skew of a few minutes must be acceptable.

Even users which use reliable NTP servers may encounter this problem over time.

This seems to me like an implementation bug on the server side. Clock checks 
should have a tolerance of +30min/-30min (or more like +10min/-50min), rather 
than +0min/-60min (which seems to be the current implementation).

Original comment by agento...@gmail.com on 27 Sep 2012 at 10:14

[GoogleCodeExporter]

Agreed: I have run into this using the Java API client

Original comment by alan.mel...@yuuguu.com on 28 Sep 2012 at 9:42

[GoogleCodeExporter]

I'm located in Europe/Copenhagen- Denmark and can't seem to get this to work 
either

Original comment by simon.se...@gmail.com on 18 Nov 2012 at 5:37

[GoogleCodeExporter]

We have made some changes to address the clock skew issues - please let us know 
if there's still an issue.

Original comment by ianbar...@google.com on 22 Mar 2013 at 2:31

• Changed state: Fixed

[GoogleCodeExporter]

I am getting this issue. Is there somewhere we can go to see what the time is 
on the server so we can make sure our clocks are correct.

Original comment by bennett...@gmail.com on 21 Jun 2013 at 8:31

[GoogleCodeExporter]

I am also getting the issue when accessing the DFA api through service account 
authentication using Java Client API

Original comment by venka...@adap.tv on 21 Jun 2013 at 10:02

[GoogleCodeExporter]

I appear to have this issue through the .NET client API ... how to remedy?

Original comment by tom.win...@pressman.co on 4 Dec 2013 at 1:54

[GoogleCodeExporter]

I am also having this issue, I have tried the clock change suggested here and 
elsewhere on the net, no solution. I am using the PHP 1.0.5-beta version

Original comment by ejike.c...@gmail.com on 26 Jun 2014 at 9:37

[GoogleCodeExporter]

Its seems to be a problem still for the php client

Original comment by abdul...@every1mobile.net on 23 Oct 2014 at 12:03