Refresh token failing to refresh: Invalid grant

[Zelab]

Hello! 
I am experiencing an issue where my spring batch data pipeline is returning an error of invalid grant on refreshing tokens.
The issue seems to be directly linked to users syncing their device with the third party app through fitbit. After the device has synced and tokens have been used sucesfully no issue occurs, but more often than not the tokens become invalid before an exchange of data completes.
 I am hoping your logs can point me in the right direction as I'm running out of ideas on how to proceed 

Thank you and best wishes, 
Nathan 

[GordonFitbit]

Hi @Zelab 

Would you please provide me with your client ID and a recent example, including timestamps, for when this problem occurred?

Thanks!

Gordon

[Zelab]

{"errors":[{"errorType":"invalid_grant","message":"Refresh token invalid: 9ac0186011ce20fdb4127c4caf0ba2976c917cd9d1d7204385797f23dfaef627. Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."}],"success":false}


this most recent example happened within the last hour on this client id 

238BYQ

[GordonFitbit]

Hi @Zelab 

I was able to find a recent scenario on Jan 30th where the user went through the authorization flow and the refresh token you used failed.   What I'm seeing is the user is going through the authorization flow multiple times.  Each time they authorization, we update the refresh token.  However, you're only storing the first refresh token (which becomes invalid after the second consent) and trying to use it.  This will fail because the first refresh token is invalid.   Remember, the user can only have 1 refresh token.   If the user goes through the authorization flow again, you will receive a new refresh token and will need to update this token for your user.   When the user completes the authorization flow, you should receive their user id which can be used to update your database.

Check out this section of documentation, https://dev.fitbit.com/build/reference/web-api/developer-guide/best-practices/#Using-Tokens-Effectiv....   It's basically describing your scenario.

Gordon 

[Zelab]

Thank you for looking into this for me Gordon, I really appreciate your response.
I can only guess I am experiencing a race condition issue because my flow is basically 

Using spring batch to bulk fetch refresh tokens from database, update the token pair and save them back to the database with the associated user identifying details.

I then fetch the fresh  UAT from the database and make a request for data  

The issue is intermittent where a users token will randomly fail to refresh, and never fail to access data and maybe like 1/100 users experience it

Thank you for your input, this has been driving me crazy to try and figure out where the issue comes from. I'm still very confused how the new refresh token is not getting saved 

[GordonFitbit · Accepted solution]

Hi @Zelab 

There is nothing wrong with updating your tokens in batch.  However, I do not recommend it for the following reasons:

1. When refreshing the tokens in batch, you don't know the frequency a user is syncing their device.   You can use the Get Devices call to see their last sync time, but this requires an additional scope the user would need to approve which they are not obligated to do.
2. You're unnecessarily updating tokens that don't need to be causing additional work for both systems.
3. When a problem occurs, the impact could be greater since there are a bunch of requests are being sent at the same time.   For example, what if there is a network issue.   Now you have a bunch of tokens being refreshed at the same time that could be impacted.   But, by refreshing the token in the natural progression of tokens lifespan and user sync pattern, the impact is more likely isolated to a single user. 
4. It makes troubleshooting the problem a little more challenging.  It's more difficult to determine when the problem started since the batch requests occur less frequently.   There are more API requests to weed through in our logs during the period the incident occurred.
5. Lastly, we see more intermittent token issues occur during batch processing.   This is likely due to the flood of token requests occuring at the same time.   

I'm sure you weighed the value of refreshing the tokens in batch.   So, think about the points I mentioned here.

[Zelab]

You make an excellent point, I suppose the best alternative is to explore the web hooks/subscription approach and refresh as required 

Thank you so much for getting back to me again, you raise an extremely valid point and I will go and venture off to the docs and start my next approach! 

Best wishes 

Nathan