Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Migrating oauth1 users to auth2 fails when fetching the first refresh_token

ANSWERED

Hey Fitbit Dev-Team,

 

I finished the implementation for oauth in ruby and successfully connected new users, using oauth2.

The next step is to migrate existing users from oauth1 to oauth2. A refresh_token request with a combination of access_token:secret as temporary refresh_token ends up in an error

OAuth2::Error: :
{"errors":[{"errorType":"oauth","fieldName":"refresh_token","message":"Refresh token invalid: users_access_token:users_secret"}],"success":false}

 

What I'am doing wrong? This is how my oauth2 client request looks in detail:

client: !ruby/object:OAuth2::Client
  id: <app_id>
  secret: <app_secret>
  site: https://api.fitbit.com
  options:
    :authorize_url: "/oauth/authorize"
    :token_url: "/oauth2/token"
    :token_method: :post
    :connection_opts: {}
    :connection_build:
    :max_redirects: 5
    :raise_errors: true
token: <users_token>
refresh_token: <users_token>:<users_secret>
expires_in:
expires_at:
options:
  :mode: :header
  :header_format: Bearer %s
  :param_name: access_token
params: {}

Or is it possible that this is available only once per user? I've a test user which I used multiple times for signing up with oauth1 and switch to oauth2.

 

Cheers Strubbelino

Best Answer
0 Votes
1 BEST ANSWER

Accepted Solutions

Issue solved, we've been using the wrong application for our staging environment.

View best answer in original post

Best Answer
0 Votes
6 REPLIES 6

Can you capture the actual HTTP request being made? It's much easier for us to diagnose the problem when we know what is actually being sent. One way to do this is with Runscope.

Best Answer
0 Votes

Thanks, I captured the request with runscope:

 

POST /oauth2/token

HEADERS Accept: */* Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3 Authorization: Basic <base64 encoded auth string> Connection: close Content-Length: 178 Content-Type: application/x-www-form-urlencoded Host: api.fitbit.com User-Agent: Faraday v0.9.1 PARAMETERS client_id: <client_id> client_secret: <client_secret> grant_type: refresh_token refresh_token: <user_access_token>:<user_secret>

 

and the respone:

Cache-Control: no-cache, must-revalidate
Content-Encoding: gzip
Content-Language: de-DE
Content-Type: application/json;charset=UTF-8
Date: Thu, 03 Sep 2015 08:25:22 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Server: nginx
Set-Cookie: JSESSIONID=CB919C76E74BFDA51C3542C27E9D30BB.fitbit1; Path=/; HttpOnly
Set-Cookie: fhttps=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
Vary: Accept-Encoding
Www-Authenticate: OAuth realm="https%3A%2F%2Fapi011-g4.prod.dal05.fitbit.com"
X-Frame-Options: SAMEORIGIN
X-Ua-Compatible: IE=edge,chrome=1

BODY view raw
{
"errors": [
{
"errorType": "oauth",
"fieldName": "refresh_token",
"message": "Refresh token invalid: <client_access_token>:<client_secret>"
}
],
"success": false
}

 

Best Answer
0 Votes

Hey JeremiahFitbit,

did you had time to check my HTTP request for obvious errors?

Best Answer
0 Votes

The request parameters should be in the body of the request, not URL parameters.

Best Answer
0 Votes

Hey Jeremiah, stil no progress.

The refresh token is still invalid when fetching oauth2 tokens the first time for existing oauth1 users. I tried now to fire an a request from runscope with the same request params as your docs describe:

Bildschirmfoto 2015-09-15 um 16.04.19.png

 

The response is still the same. Are you sure you're not missing anything in the docs like Base64 encoding or something?

 

Bildschirmfoto 2015-09-15 um 16.03.55.png

Best Answer
0 Votes

Issue solved, we've been using the wrong application for our staging environment.

Best Answer
0 Votes