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

Refresh Token when Fitbit API is down.

ANSWERED

Hello all,

 

I am trying to keep a working communication with my experimental App and my Fitbit account but, when the Fitbit API encounter, the Refresh token most of the times becomes useless.

 

The only way to resolve this is to open my App and re-grant access with my Fitbit account. This creates a new login to my App and creates a new Refresh Token.

 

Since I have already granted access to my App, isn't there a way to keep communication auto-refreshing without asking the user to open my App and re-grant access?

Best Answer
0 Votes
1 BEST ANSWER

Accepted Solutions

Hi @AkisAkakis,

 

It sounds like your application is using the Implicit Grant Flow. With this flow, you'll need to go through the authorization flow each time your access token expires. Access tokens obtained through this flow have optional expiration times of 1 day, 7 days, 30 days, or 1 year.

 

If you don't want to login each time grant consent, I recommend using the more secure Authorization Code Grant Flow. Access tokens obtained through the Authorization Code Grant Flow have a default expiration of 8 hours. When the access_token expires, your application will use the refresh_token Fitbit provided to your application along with the access_token after consent, and exchange it for a new access_token and refresh_token pair without sending the user through the authorization flow again. See the flow below:

 

  1. Your application presents the Fitbit authorization page to the user by calling the "authorize" endpoint. See Authorization Page below.

  2. The user consents to share their Fitbit data with your application by enabling some or all scopes. Upon the user’s initial consent, Fitbit redirects the user back to your application using the redirect or callback URL with an authorization code as a URL parameter.

  3. Your application exchanges the authorization code it receives from step 2 for an access token and refresh token pair. See Access Token Request below. Your application should store the access token and refresh token.

  4. The application uses the access token to execute API calls. The refresh token is used to renew the access token when it expires without having to re-prompt the user.

  5. Access tokens created through the authorization code grant flow have a lifespan of 8 hours. When the user’s access token expires, your application will use the refresh token to obtain a new access token and refresh token pair. See Refreshing Tokens. Refresh tokens can only be used once. Therefore, the old refresh token should be discarded and your application should store the new access token and refresh token pair.

I hope this helps. Let me know if you have any questions.

View best answer in original post

Best Answer
0 Votes
2 REPLIES 2

Hi @AkisAkakis,

 

It sounds like your application is using the Implicit Grant Flow. With this flow, you'll need to go through the authorization flow each time your access token expires. Access tokens obtained through this flow have optional expiration times of 1 day, 7 days, 30 days, or 1 year.

 

If you don't want to login each time grant consent, I recommend using the more secure Authorization Code Grant Flow. Access tokens obtained through the Authorization Code Grant Flow have a default expiration of 8 hours. When the access_token expires, your application will use the refresh_token Fitbit provided to your application along with the access_token after consent, and exchange it for a new access_token and refresh_token pair without sending the user through the authorization flow again. See the flow below:

 

  1. Your application presents the Fitbit authorization page to the user by calling the "authorize" endpoint. See Authorization Page below.

  2. The user consents to share their Fitbit data with your application by enabling some or all scopes. Upon the user’s initial consent, Fitbit redirects the user back to your application using the redirect or callback URL with an authorization code as a URL parameter.

  3. Your application exchanges the authorization code it receives from step 2 for an access token and refresh token pair. See Access Token Request below. Your application should store the access token and refresh token.

  4. The application uses the access token to execute API calls. The refresh token is used to renew the access token when it expires without having to re-prompt the user.

  5. Access tokens created through the authorization code grant flow have a lifespan of 8 hours. When the user’s access token expires, your application will use the refresh token to obtain a new access token and refresh token pair. See Refreshing Tokens. Refresh tokens can only be used once. Therefore, the old refresh token should be discarded and your application should store the new access token and refresh token pair.

I hope this helps. Let me know if you have any questions.

Best Answer
0 Votes

John, 

I'm not sure if you're still monitoring this, but we have tried steps 1-5 however after day 1 when we try to access data again, we get the following type of error:

 

 

{

    "errors": [

        {

            "errorType": "invalid_grant",

            "message": "Authorization code invalid: 87bb9f380952139f8988ff47191c9219b8128157 Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."

        }

    ],

    "success": false

}

 

Any recommendations on how to fix such that we can continue to grab data from the user passively after day 1?

 

Best Answer
0 Votes