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

OAuth 2.0 access_token expire issue

Hi,

I am developing an application where I need to fetch the registered users data from fitbit to offline access(data proccessing on my local server.) periodecally. I am using OAuth 2.0 Authorization Code Grant which gives me access_token to use for API calls. But access_token is short lived for 1 hours duration and expires after this. I know we can use refresh_token to renew the access_token but it will again expire and we have to use the refresh token. Also refresh_token can used once so it will lead you nowhere. I am looking for solution for current scenario.

Also will it be fixed once we are done with OAuth 2.0 beta?  

 

Thanks

Best Answer
0 Votes
18 REPLIES 18

This is the OAuth2.0 behavior. The access token lives for a short time, and you need to call the refresh token to renew.
After every renew you got a new refresh token with the access token also.

Best Answer

@PKT wrote:

Hi,

I am developing an application where I need to fetch the registered users data from fitbit to offline access periodecally. I am using OAuth 2.0 Authorization Code Grant which gives me access_token to use for API calls. But access_token is short lived for 1 hours duration and expires after this. I know we can use refresh_token to renew the access_token but it will again expire and we have to use the refresh token. Also refresh_token can used once so it will lead you nowhere. I am looking for solution for current scenario.

Also will it be fixed once we are done with OAuth 2.0 beta?  


There is nothing to fix—this is the intentional design and conforms to the OAuth 2.0 framework.

 

There is no concept of "offline access", as you can use an OAuth 2.0 access token from your server or client-side regardless if the user is currently engaged with your application or not.

 

The refresh token should only be done server-side, as it requires your application secret, which should never be distributed in client code. If you do not have a server and are purely client-side, you can use the Implicit Grant Flow to obtain a token that lives as long as 30 days, but people will have reauthorize your app after 30 days.

Best Answer

Hi ,

Thanks for your reply. Actually offline access is some data processing on my server. I am doing all the things on my server side. The only problem that I am facing is to access token expire. So if the access token will expire so frequently, then user have to authorize himself for every now and then. 

 

If there can be a approach by which user have to authorize himself only once and then my application will always able to fetch the data from fitbit server with stored access token.

 

Thanks

Best Answer
0 Votes

You can refresh the access token without the user.
I dont get your problem.

In my server, i'm refreshing the tokens before every call and its work (but not the most efficient)

Best Answer
0 Votes

Yeah, I agree with you that we can refresh access token with refresh_token. But if refresh token gets failed to get the new access_token then you have to do the auth process with user. I per my understanding you can use refersh_token only once.

 

Please suggest.

Best Answer
0 Votes

"But if refresh token gets failed to get the new access_token then you have to do the auth process with user."
No.

If you use the refresh token you will get a new access token and a new refresh token. You need to use the new one.
If the refresh token failed that mean:
-the user de-authorize your application
-you are not use the lastest tokens

Best Answer
0 Votes

Yeah we are on the same page. I'm doing the exactly same thing like replacing the refresh tokens after every call for new access token. But suppose if call gets failed, then what will happen because you cannot reuse the refresh token.

Best Answer
0 Votes

@PKT wrote:

Yeah we are on the same page. I'm doing the exactly same thing like replacing the refresh tokens after every call for new access token. But suppose if call gets failed, then what will happen because you cannot reuse the refresh token.


If the refresh token request fails, it means that your refresh token is invalid because it has been used by you already or the user has revoked access.

Best Answer
0 Votes

Hi,

I am sending expire_in = 2592000 as part of auth URL but the expiry time for access_token always getting 3600 ie 1hour. could you please provide details of how to set the expiry time of access-token to 30days. 

AUTH_URL = "https://www.fitbit.com/oauth2/authorize?" +
"response_type=code" +"&client_id="+CLIENT_ID+
"&redirect_uri="+REDIRECT_URI+"&expires_in="+VALUE_EXPIRES_IN+"&prompt="+VALUE_PROMPT+"&scope="+ API_ACCESS_SCOPE_WRITE

 

Best Answer
0 Votes

Hello,

you cant change the expire time.

Best Answer
0 Votes

please check the API documentation and it says you can choose 1 day or 1 week or 30 days:

https://dev.fitbit.com/docs/oauth2/#authorization-page

Best Answer
0 Votes

"For use with the Implicit Grant flow only."

https://dev.fitbit.com/docs/oauth2/#authorization-page

 

Since you have specified "response_type=code", you are using the Authorization Code flow and not the Implicit Grant flow.

Best Answer

Hi, I am refreshing the new token every 30 minutes and, obviously, I get the new refresh token. I have one sample user for the moment, so I am sure that there is no real user revoking access to the app. I am also sure that the same sample user is not being used in any other app. My app keeps working for several hours until I get a Refresh Token Expired message. This would happen sometimes after 2 hours of using the app, other times after 8 hours. It is totally random. Any reason for that? Or anything specifically you suggest that I need to check in my software? Thanks.

Best Answer

@Lioneng Why are you refreshing the token every 30 minutes?

 

Refresh tokens don't expire so I assume you mean the access token is expired, in which case, you're using the old access token instead of the new one. When you refresh a token you need to store the new refresh token and the new access token.

Andrew | Community Moderator, Fitbit

What motivates you?

Best Answer
0 Votes

I am experiencing the random token expiration period like in the previous comment in this thread. I am already handling the token refresh when I get the expired_token 401 error but I want to predict offline if the token expired and I would expect it happens in the 8 hours set as default but sometimes it happens in 2 hours or less, Is there any reason for that?

Best Answer
0 Votes

Each token expires by default in 24 hours since it was issued.

You can provide expires_in parameter when you requesting token to change default expiration time: https://dev.fitbit.com/reference/web-api/oauth2/#authorization-page

That's being said, all the tokens are expire exactly at the time of "exp" key that is part of token itself. 

So you can get expiration time from each token itself. Every token is just base64 encoded json. If you decode it you'll see the expiration time of this token. This is what Fitbit servers use to detect if token is expired or not. Check the "exp" field to detect if token expired or not even without sending it to Fitbit servers. 

Also you can use jwt.io website and paste your token there and see it's insights.

Best Answer

Is it possible to refresh token in implicit grant flow as like authorization grant flow?

Best Answer
0 Votes

Hi @Navindas 

 

The Implicit Grant flow does not support refresh tokens.  However, you can set the access_token to expire up to 1 year.  Here's the link to the documentation.

Gordon Crenshaw
Senior Technical Solutions Consultant
Fitbit Partner Engineering & Web API Support | Google
Best Answer
0 Votes