12-08-2015 14:20
12-08-2015 14:20
Under what circumstances does a refresh token become expired? Or a previously valid refresh token for the same application become invalidated?
I encountered this issue recently where most of our refresh tokens had been made invalid and had to write additional redundancies into the application. It's quite possible that another developer had made a mistake, but I also experienced the same problem within my environment that was unchanged for 2 weeks.
Answered! Go to the Best Answer.
11-22-2016 09:43
11-22-2016 09:43
@AndrewFitbit wrote:
@sachins If you failed to store the new token from the initial response, there's a two-minute window where you can use the old refresh token and it will return the same response. You can read more about refreshing tokens on our docs.
@HirenG Going off of this, if you didn't store the new token and your current one has already been used, then you'll need to contact private support.
01-20-2017 04:21
01-20-2017 04:21
what a nightmare.
05-08-2018 10:15
05-08-2018 10:15
What happens if you update your client secret? Will all users be logged out (access and refresh tokens expire) so they have to log back in?
06-22-2019 07:22
06-22-2019 07:22
Not in our case
A user connect/authorizes an access_token and refresh_token are received.
If the user then goes to sleep and tries the next day. the access_token is expired which would be correct
but so is the refresh_token
Correct me, but calling oauth2/introspect with an expired access_token. will this effect the refresh_token validity.
User gets data and all is well, use goes to sleep or has no data for > 3 hours.
We get a subscription message, that the user has data (say activities)
We then call introspect to check the token status we get success: false and error_type: expired_token message: access token expired
So we then call /token (to refresh) grant_type=refresh_token&refresh.... to get a new access_token
and the result is invalid_grant Refresh token invalid
Based on these results introspect expires the refresh_token, which should not be the case.
Or Why does the call to /token to refresh the access_token using the current refresh_token do we get Refresh token invalid.
No the use has not obtained a new token, no the user has not reauthorized, no the user has not revoked anything. the user simply had >3 hours between the successful last call and now the new call.
Please let us know.
06-24-2019 17:25
06-24-2019 17:25
Hi @rollingstrong,
Yes, the access_token will expire but the refresh_token never does. However, the refresh_token can only be used once. After the refresh_token has been used to get a new access_token and refresh_token, the old refresh_token becomes invalid. Therefore, you should make certain to keep track of the access and refresh tokens.
The oauth2/introspect endpoint should not affect the refresh_token.
We only keep our log data for 7 days. Have you been able to reproduce this problem recently? If so, would you please private message me your client ID. I can see what your application is doing.
Gordon
06-25-2019 07:03 - edited 06-25-2019 07:15
06-25-2019 07:03 - edited 06-25-2019 07:15
Hi GordonFitbit
Thanks for the reply
We do keep track of the refresh and access_tokens
When first received they are stored together,
when the access_token expires and the refresh_tokens works! the newly received access_token and refresh_token replaces the original. thus they too are stored.
However as outlined before
During the day the access_token does expire and the refresh_token gets the new access_token
this works fine, as the subscription notice comes in about every hour +/-
But at night the user does not get any data and first thing the next morning the refresh_token AND access_token have BOTH expired and thus the user has to re-authenticate (a very bad experience)
This is becoming critical and we really need an answer here, please...
we receive a subscription.
we call introspect to get the token status
(a) if valid we call the data in the subscription
(b) if invalid/expired/etc.. we use the refresh_token to get a new access_token
now with the new access_token we call the data in the subscription
during the day this works great, first thing the next morning both tokens have expired. (bad user experience) why ? ? ? ?
I have pm you
03-12-2020 00:11
03-12-2020 00:11
Have you had any success getting this issue resolved?
I'm having the exact same issue at the moment...
03-12-2020 05:18
03-12-2020 05:18
I gave up on this api. The refresh tokens logic logic is really flawed. It should be such that, that refresh tokens don’t expired until first use of the new access token. Or if that is not possible for Fitbit, then at the very least only if the client app returns a successful response. Too many things may happen before the client app can get the new tokens persisted.
03-12-2020 15:19
03-12-2020 15:19
Hi @Nico_rhns
There are 3 main reasons for refresh token issues which we've documented in our troubleshooting guide, https://dev.fitbit.com/build/reference/web-api/troubleshooting-guide/common-solutions/#refresh-token.... If you would provide me with your client ID and the exact error you're receiving, I can try to figure out what the problem is.
Gordon
02-25-2021 04:58
02-25-2021 04:58
@Gordon-C
Hello.
Our development system have similar issue.
For check error detail, is it okay I write "Client ID" to this public post?
Until happen trouble, it was able to refresh without problems.
02-25-2021 06:37
02-25-2021 06:37
I properly not understood it so I wrote above comment.
https://dev.fitbit.com/build/reference/web-api/help
I decided to question from this form.