Using Refresh Token to Retrieve New Authentication Token

[RyanJPlant]

I'm able to use token <- fitbitr::oauth_token() to generate the initial authentication and refresh tokens following browser authentication, however, once the authentication token expires, I can't seem to use the refresh token to generate a new authentication token.

Running token$token$refresh() gives me the following error:

Error in refresh_oauth2.0(self$endpoint, self$app, self$credentials, self$params$user_params,  : 
  Unauthorized (HTTP 401).

Is this feature implemented already, or does the token refresh need to be managed directly by writing the httr code to handle the process? If it isn't, I would say this would be quite an essential update to this wonderful r package.

[MarloesEeftens]

Same here, very useful package (thank you!), but am hitting the same roadblock as RyanJPlant: after initial authentication, the session (obviously) times out. I'd like to extract more data from the same account periodically, so to extract a refresh token & be able to generate a new authentication token would be great. Any ideas?

[andrewheiss]

A different R package for accessing the FitBit API has a load_cached_token() function that allows the OAuth token to be cached and loaded without needing reauthorization. Would it be possible to do something similar here? I've been incorporating FitBit API data into a dashboard, but the inability to keep an active token alive has been a tricky hurdle.

Thanks!

[MarloesEeftens]

A different R package for accessing the FitBit API has a load_cached_token() function that allows the OAuth token to be cached and loaded without needing reauthorization. Would it be possible to do something similar here? I've been incorporating FitBit API data into a dashboard, but the inability to keep an active token alive has been a tricky hurdle.

Thanks!

Thanks @andrewheiss! I had sort of parked this issue for a while but will need to come back to it soon. Looks like the "other" package you suggest is also called fitbitr and has been updated more recently, but still under development? If you don't mind, do let me know if & when you solve somehow? I'll do the same... ;-)

[andrewheiss]

@MarloesEeftens I figured out the reason it's broken (🎉), but haven't figured out how to fix it.

According to the FitBit API documentation (https://dev.fitbit.com/build/reference/web-api/oauth2/#authorization-header), the API authorization request has to include a header named "Authorization" with the key and secret encoded with base64 and prefixed with "Basic: "

Getting a token with httr initially seems to work automatically, but it seems that httr's refresh() function doesn't work. I've found a couple other workarounds where people basically copied httr::refresh_oauth2.0() and added the base64 headers manually:

• refresh_fitbit_token() from yet another package named fitbitr (https://github.com/Avsecz/fitbitr/blob/master/R/basic_api_functions.R#L165): This is a wrapper function that has to be called manually when the token expires
• Charlotte Wickham's custom httr functions (https://gist.github.com/cwickham/81be4a3c2f6eb8caa94d): These seem to be replacement versions of the Token2.0 R6 object with methods of obtaining and refreshing tokens with base64 encoding. That means that in theory, there's no need to manually use the function—if you run GET(url = url, config(token = token)) and the token is expired, httr will automatically refresh the stale token, just like it does with a regular OAuth token

The tricky part is that both of those base64-enabled workarounds are adapted from older httr code (the other other fitbitr's refresh_fitbit_token() is from 2016; Charlotte's gist is from 2015), so I haven't been able to get it to work by just copying/pasting the code, since something in httr seems to have changed.

The best solution is probably to do something like Charlotte did and replace the R6 object so that it'll automatically refresh as needed, but that seems tricky. I've also been scouring the httr documentation to see if there's some built-in way to adjust the POST headers without needing to recreate functions, but so far haven't found a way.