Some refresh tokens work, others don't

[robbiet480]

I sent an email to Fitbit last Thursday about this problem and have yet to hear back after repeated emails, so I'm going to try here. I'm sure you're busy and it was unintentional.

We recently migrated to OAuth 2.0 from OAuth 1.0. Most of our users seem fine (tokens are refreshing once an hour without problem), but we have some (a number as high as 800 out of 2500) that are continually seeing responses like "Refresh token invalid: <refresh token here>" when trying to refresh a users token at https://api.fitbit.com/oauth2/token. We strongly believe there is a problem on Fitbit's side, since most of our users can refresh fine constantly. We have ruled out revocation of tokens. We have implemented many different OAuth 2.0 providers in this application before and have never had these kind of issues. There is little documentation around the refresh tokens but we assume that it is IETF standards compatible (our understanding being that as long as we have a valid refresh token we should be able to get a new access token regardless of the expiration of the access token itself). We have seen the problem with both long time users and new signups.

We've been able to migrate the broken users back to OAuth 1.0a and then back to OAuth 2.0 to be able to authenticate them again but this is only a stopgap measure. We will need to ask users that have signed up after we migrated production to OAuth 2 to re-connect their Fitbit account as we don't have OAuth 1.0a tokens to revert to.

For the majority of users, token refreshing works great every time. But there are some users that we are unable to refresh for unknown reasons.

This is stopping us from fully switching to OAuth 2.0 and any help would be greatly appreciated. If we can't get this figured out soon we will need to revert back to OAuth 1.0a.

Thanks

[JeremiahFitbit · Accepted solution]

The refresh tokens work exactly one time. Immediately after they are used, they are invalidated, and repeat requests will fail. Are you absolutely certain that you're only making one refresh request and storing the new refresh token?

We've been using OAuth 2.0 with the refresh tokens in a few of our own services for over 6 months. Every time that we've seen what you're describing, it's been a problem with the integration, not the Fitbit Web API.

We've seen with our own services how it is very easy to have race conditions with refreshing token when there are many worker processes using the same access token. If there are multiple concurrent jobs that are running on behalf of the same user, they both see the access token has expired, both try to refresh, and only the first will succeed.

If you are able, I recommend putting a tool like Runscope Traffic Inspector in between your application and the Fitbit Web API just for OAuth requests. This will give us exact requests and response logging to identify the source of the issue.

[robbiet480]

For anyone reading this, we finally traced it down to a totally unrelated issue. It wasn't anything wrong with Fitbit.

Thanks for the pointers though @JeremiahFitbit! The race condition suggestion was a good tip (it wasn't the problem in the end but we found it thanks to looking in that area)

[Qualcee]

Please read my post https://community.fitbit.com/t5/Web-API/Refresh-token-no-good-after-fitbit-server-times-out/m-p/1200...

One time use refresh tokens are vulnerable to network failures that end up preventing legitimate clients from accessing data for users that they have been given access to.