Refresh token & network timeout

[shurik]

Regarding refresh tokens, is the following correct?

* There is only one valid refresh token at any given time

* Refresh token is re-ussed and the old token is invalidated every time the "refresh token request" is sent to Fitbit

If that's correct then we have the following situation

1. We sent a "refresh token" request. The request has timed out (we have a network timeout exception on our side). We never got the responce back due to a random network issue. But it looks like the request itself did reach Fitbit servers and tokens were re-issued on Fitbit side.

2. We retried with the old tokens and got "Refresh token invalid or expired".

Basically if refresh token request fails like described above there is no way to retry. The sync is performed by a background app without user intervention so we cannot "redirect to Fitbit for re-authentication" when this happens.

Does it make sense? Any advice how to mitigate this issue? This happened only once so far but because refresh token requests are being sent pretty often I think this will happen again.

[Qualcee]

Has this update been released? Is the cutover still scheduled for the 14th?

[JeremiahFitbit]

The refresh token grace period should be in Wednesday's release.

The 1 hour blackout test is still scheduled for March 14th (see this topic). The OAuth 1.0a removal is still scheduled for April 12th.

Edit: updated the expected release date.

Edit 2: updated the expected release data again. We had to roll back today's release for unrelated issues.

[JeremiahFitbit]

The refresh token grace period was released this afternoon (Wed, March 9 PST).

[SunsetRunner]

I am getting CloudFlare timeouts returning status 522 - they are reasonably common. I was wondering where the servers were because we are accessing them from AWS in Sydney. Perhaps CloudFlare in Sydney has more issues than elsewhere - the timeout is between CloudFlare and Fitbit Servers (SoftLayer?) 

"The initial connection between CloudFlare's network and the origin web server timed out."

On the Oauth2 implementation - I am not sure how forcing everybody using the API to refresh tokens several times an hour (because of the consequences of this not working to usability for the user) - is much of an advantage over Oauth1 (which we *never* had problems with).

So - I would hazard a guess that nobody using the API is going to do one-shot requests for data. Setting the refresh to 60 min is just increasing the load on your servers making the timeout issue worse. 

Can I request that the refresh limit is extended to something more reasonable like 24 hours?

[JeremiahFitbit]

---

@SunsetRunner wrote:

I am getting CloudFlare timeouts returning status 522 - they are reasonably common. I was wondering where the servers were because we are accessing them from AWS in Sydney. Perhaps CloudFlare in Sydney has more issues than elsewhere - the timeout is between CloudFlare and Fitbit Servers (SoftLayer?) 

"The initial connection between CloudFlare's network and the origin web server timed out."

---

@SunsetRunner: If you're getting a 522 error from CloudFlare, that is a different issue. Please contact private support with your client id and the UTC time of the error.

You should set the timeout for refresh token requests to less than 30 seconds. If for some reason the request succeeded, but the response was lost, you can make make the same request again for up to 2 minutes.

---

OzTechMuse wrote:

On the Oauth2 implementation - I am not sure how forcing everybody using the API to refresh tokens several times an hour (because of the consequences of this not working to usability for the user) - is much of an advantage over Oauth1 (which we *never* had problems with).

---

OAuth 1.0a and OAuth 2.0 have completely different security models. OAuth 1.0a relies on private client secrets and access token secrets. OAuth 2.0 relies on frequently rotating access tokens that are easily revocable.

---

@SunsetRunner wrote:
So - I would hazard a guess that nobody using the API is going to do one-shot requests for data. Setting the refresh to 60 min is just increasing the load on your servers making the timeout issue worse. 

Can I request that the refresh limit is extended to something more reasonable like 24 hours?

---

As I mentioned above, you can use the same refresh token multiple times within 2 minutes of its first use. Your app shouldn't refresh a token until it actually expires. There is no reason for your app to regularly refresh the token multiple times an hour.

A 522 error from CloudFlare is not a server load issue, but Fitbit is far more concerned about user security than server load.