I've had some problems like a lot of people with refresh tokens. I also have done several OAuth2 implementations. I've gone so far as to logging every request and response to make sure I save the new refresh token after I make a refresh access token call.
In general it's working. Sometimes it just fails. The problem is that there is no room for error. When we are trying to collect data for a user that does not log in regularly, losing acess to their data is a major problem.
Yesterday I had 3 connection time out issues, 1 of which invalidated the refresh token.
Issue 1. I got this response from fitbit:
Response: HTTP/1.1 522 Origin Connection Time-out
X-Frame-Options: SAMEORIGIN
Date: Tue, 23 Feb 2016 23:57:49 GMT
Transfer-Encoding: chunked
CF-RAY: 2796dfacc3a02258-LAX
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Server: cloudflare-nginx
Pragma: no-cache
<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en-US"> <![endif]-->
<!--[if IE 7]> <html class="no-js ie7 oldie" lang="en-US"> <![endif]-->
<!--[if IE 8]> <html class="no-js ie8 oldie" lang="en-US"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en-US"> <!--<![endif]-->
<head>
<meta http-equiv="set-cookie" content="cf_use_ob=0; expires=Tue, 23-Feb-16 23:58:18 GMT; path=/">
<title>api.fitbit.com | 522: Connection timed out</title> In this case, the refresh token still worked. I'm guessing this is because we never got to the actual fitbit application server.
Issue 2. My java socket timed out. "java.net.SocketTimeoutException: Read timed out", which means I never got a response from the fitbit server. In this case the refresh token still worked next time. Again I also assume that the request didn't make it to the fitbit application server.
Issue 3. Again java socket timed out. This time, the refresh token was no good on the next use. I'm assuming that this did in fact get to the fitbit application server, but never made it back to me in time.
My java socket timeout is set to 30 seconds. And now I can't collect data for this user. All of our systems are not perfect and we need a solution for this.
I think you need some flexibility on refresh tokens. It might be as simple as just adding an api that, since fitbit knows that the user hasn't revoked access, but I need a clean refresh token, I can call an api with my credentials, and the user id and in return get a clean refresh token. Maybe even include the refresh token I have, so you can check some history. Maybe just stop changing the refresh token. According to the oauth2 spec https://tools.ietf.org/html/rfc6749#page-10, giving a new refresh token is optional.
There are reasonable solutions which make this api access more flexible, yet still secure.
