Issue with refreshtoken, sometimes failing with 'invalid_client'

Hi, my app is able to refresh tokens most of the times, but from time to time it fails with 'invalid_client'. Here is a history of calls from today, 6/1, PDT. Could there be some problem in the servers? or something that the code is sending that leads to this error?

07:58:01 try to refresh code
https://api.ecobee.com/token?grant_ty...

07:58:02 receive response
{
"access_token": "VoEPTUxcrBhqmjookuBe5UblyRXXXXXX",
"token_type": "Bearer",
"expires_in": 59,
"refresh_token": "jAHjgmo7bo5UOIxJUTdmKcNN3UXXXXXX",
"scope": "smartRead,smartWrite,ems"
}

09:06:37 try to refresh code
https://api.ecobee.com/token?grant_ty...

09:07:13 receive response
{
"access_token": "4CLoIkZDwVfHYtWecFNTTEWJ1xXXXXXX",
"token_type": "Bearer",
"expires_in": 59,
"refresh_token": "uqoSKSoaJM9TTtYqiG8m9hzg5zXXXXXX",
"scope": "smartRead,smartWrite,ems"
}

10:21:45 try to refresh code
https://api.ecobee.com/token?grant_ty...

receive response
{
"error": "invalid_client",
"error_description": "Authentication error, invalid authentication method, lack of credentials, etc.",
"error_uri": "http://tools.ietf.org/html/draft-ietf..."
}

Thanks for any help or pointers on why could this be happening.

I've obfuscated here all tokens and app IDs - I changed the last 6 characters to XXXXXX.

-B
1 person has
this problem
+1
Reply
  • ScottF (Official Rep) June 01, 2015 20:15
    Hi,
    I have checked out logs and the problems are stemming from the fact that you application is sending the same request twice.
    This is happening quite frequently, for example at 10:29 today, and also earlier at 10:16.
    I could provide more examples from previous calls if you like, but can you take a look at your code and try to address this please?

    Scott
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Scott, thanks for the help.

    I've been doing tests with the app the last 3 days, to try to find out when is the app failing to connect. At 10:29 today (a few minutes after the last call above) I sent the call a second time, after it had failed at 10:21. The current app logic is if the app fails with 'invalid client' it might try again. If the app had not failed at 10:21, it would not have called it again.

    I can change the code to *not* call again once it fails once, though the question is why did it fail at 10:21:45?

    -B
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • ScottF (Official Rep) June 01, 2015 20:37
    Apologies,
    I wasn't allowing for the time difference. Those two examples I referred to above are in EST.

    You request at 10:21 (13:21 EST) failed because a call to get a refresh token using that same token (begins with uqoSKSoaJM9TTtYqiG8m9hzg5) was made initially at 10:18 (13:18 EST) which was successful. At 10:21 (13:21 EST) the same request, using the same token was made again.

    Scott.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Interesting - my code has no record of making a call at 10:18, only the request at 10:21. I'll have to check how/why is this happening. This information is very useful, thanks.

    Bernardo
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Scott, just wanted to thank you for the previous investigation. It allowed me to find a very nasty/obscure bug in my code that had always been there. It has now been fixed.

    FYI, the issue is that if an app is no longer running in the foreground in the mobile OS its using (i.e. user moves to another app), the app should stop. In fact it does stop almost all the code, though for unknown reasons the OS still allows the code to run from time to time. One of the pieces of code that runs is to check if a token has expired. If it expires, it calls for a token renewal. Alas, as the app is really 'sleep', the OS does not give it permission to store any data or respond to external calls, so the app calls the function to refresh the token, but cannot get response, and can't even write the event to a local log file.

    So now I added some workarounds to the app to *really* stop the code from running in the background.

    Bernardo
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated