Invalid or expired refresh tokens

[jmitchell38488]

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.

[Bonxy]

Hi there,

Using oAuth2 a refresh token will expire every hour.

You can see the refresh token expire time in the response from fitbit.

{
    "access_token": "eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0MzAzNDM3MzUsInNjb3BlcyI6Indwcm8gd2xvYyB3bnV0IHdzbGUgd3NldCB3aHIgd3dlaSB3YWN0IHdzb2MiLCJzdWIiOiJBQkNERUYiLCJhdWQiOiJJSktMTU4iLCJpc3MiOiJGaXRiaXQiLCJ0eXAiOiJhY2Nlc3NfdG9rZW4iLCJpYXQiOjE0MzAzNDAxMzV9.z0VHrIEzjsBnjiNMBey6wtu26yHTnSWz_qlqoEpUlpc",
    "expires_in": 3600,
    "refresh_token": "c643a63c072f0f05478e9d18b991db80ef6061e4f8e6c822d83fed53e5fafdd7",
    "token_type": "Bearer"
}

After the 3600 seconds, the token will have to be refreshed again.

[jmitchell38488]

Hi Bonxy,

You're refering to the Access Token that expires every hour.

---

Using oAuth2 a refresh token will expire every hour.

You can see the refresh token expire time in the response from fitbit.

After the 3600 seconds, the token will have to be refreshed again.

---

This isn't the error I'm asking about. There's a specific API error for refresh tokens that states:

"Invalid or expired refresh token".

This problem occurs when a consumer is attempting to fetch a new access token using the refresh token. The refresh token is used to obtain a new access token once the access token has expired.

With regards to the access token & refreshing the access token, this works fine and we have no problem with it. The refresh token, as far as the API docs says, shouldn't expire, but in our case it did for every user that we had.

https://dev.fitbit.com/docs/oauth2/#refreshing-tokens

POST https://api.fitbit.com/oauth2/token
Authorization: Basic Y2xpZW50X2lkOmNsaWVudCBzZWNyZXQ=
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=abcdef01234567890abcdef01234567890abcdef01234567890abcdef0123456

That works fine, however we have encountered behaviour when the refresh token becomes expired or invalid. I encountered this after more than 2 weeks of inactivity.

[Bonxy]

Gotcha.

Doesnt the access token expire if a user logs out of your app or revokes your apps access.

With Fitbitly, peoples access tokens change when the log out of the site and then log back in using Fitbit.

[jmitchell38488]

---

@Bonxy wrote:
Gotcha.

Doesnt the access token expire if a user logs out of your app or revokes your apps access.

With Fitbitly, peoples access tokens change when the log out of the site and then log back in using Fitbit.

---

If a user revokes access, then yes, absolutely the access should be reset. But this isn't what happened, since I have control of one account and access wasn't revoked, and other users had the same problem when they didn't revoke access either.

If a user logs out, it is possible that this is the case, and if so, then this is wrong, since the user shouldn't be theoretically 'logged in' to synchronise from FitBit, since they're already granted permission, and you're providing valid authorization credentials.

Access tokens changing is fine, but I'm more curious about why the refresh tokens were suddenly invalidated in general. If it only happens when revoking permission, then I'll need to let the product team know, but if it happens under other occasions, such as product changes or releases, they also need to be aware of that.

[Bonxy]

I see your problem.

In my instance, ive only ever seen it change when they have re-auth'd with my site.

Maybe fitbit can expand a bit more on your issue.

[Bonxy]

Also, you didnt do any changes to your app did you ? For instance changing it to read & write etc ?

[jmitchell38488]

Nope, which is why I thought it strange that the refresh token expired.

[jmitchell38488]

@SunsetRunner is there any information regarding this question? It isn't discussed in the API documentation, but still exists an error, so there must be an edge case for it.

[SunsetRunner · Accepted solution]

Refresh tokens can be invalidated/expired in these cases

1. User revokes access to your application

2. The refresh token is used to obtain a new access token and new refresh token

3. The user goes through the Authorization process again and gets a new refresh token

(At any given time, there is only 1 valid refresh token.)

[jmitchell38488]

Thanks for clearing that up, I'll pass it on to our product team.

[Bonxy]

Would love to hear your outcome if you post it back.

[jmitchell38488]

---

@Bonxy wrote:
Would love to hear your outcome if you post it back.

---

I suspected as much as DanC said and also some of the points that you raised earlier. Since we have a synchronisation task that downloads basic information from FitBit (Calories out, steps, weight etc.) that's triggered by the user, it assumed that an authorised user was always authorised.

I added more error handling around making authenticated requests in the consumer, rather than the library, that checks if the user is authorised, has valid access token and can refresh their token (if access is expired), if anything fails it sends the user back to the authorisation page and tells them an error occured. Error handling already existed and any exceptions always ended fitbit execution, but nothing existed previously (until last week) to handle exceptions with the refresh token.

An interesting edge case.

[jmitchell38488]

---

@SunsetRunner wrote:

Refresh tokens can be invalidated/expired in these cases

1. User revokes access to your application

2. The refresh token is used to obtain a new access token and new refresh token

3. The user goes through the Authorization process again and gets a new refresh token

(At any given time, there is only 1 valid refresh token.)

---

@SunsetRunner @JeremiahFitbitIs it possible that this could be added to the API documentation?

[gwsyzygy]

---

@SunsetRunner wrote:

Refresh tokens can be invalidated/expired in these cases

1. User revokes access to your application

2. The refresh token is used to obtain a new access token and new refresh token

3. The user goes through the Authorization process again and gets a new refresh token

(At any given time, there is only 1 valid refresh token.)

---

Only 1 valid refresh token per what?  UserID + ClientID?  UserID + ClientID + IP Address?  Initial auth token?  What is your "session" uniqueness?  I have an app that I authorize per instance, and it refreshes just fine as long as only one "instance" is run but as soon as I run more than one (not even concurrently) it seems "last in wins".  The "instances" are Unit Tests, a debug build app, and a release build app.  I authorize and store tokens for each independently, but as soon as one refreshes, none of the others are able to refresh and only get invalid_grant: Refresh token invalid back.

Is anyone else having problems running the same oauth2 app (for same userid) in separate contexts/different devices?

[CodeLikeThis]

@SunsetRunner the documentation at https://dev.fitbit.com/docs/oauth2/#refreshing-tokens still says only "A refresh token does not expire until it is used." Can you please update the docs with your 3 cases? 

Also, technically, none of your 3 cases is *expiring* (which means "becoming invalid after a time") but *invalidating*.

[JeremiahFitbit]

---

@gwsyzygy wrote:

---

@SunsetRunner wrote:

(At any given time, there is only 1 valid refresh token.)

---

Only 1 valid refresh token per what?  UserID + ClientID?  UserID + ClientID + IP Address?  Initial auth token?  What is your "session" uniqueness?  I have an app that I authorize per instance, and it refreshes just fine as long as only one "instance" is run but as soon as I run more than one (not even concurrently) it seems "last in wins".  The "instances" are Unit Tests, a debug build app, and a release build app.  I authorize and store tokens for each independently, but as soon as one refreshes, none of the others are able to refresh and only get invalid_grant: Refresh token invalid back.

Is anyone else having problems running the same oauth2 app (for same userid) in separate contexts/different devices?

---

@gwsyzygy:

If your application is using the Authorization Code Grant Flow, a person who authorizes your application may have multiple valid access tokens, but only ever 1 valid refresh token.

Your application should store an access token and a refresh token for each person who authorizes your application.

Once your application (represented to the Fitbit API using your client id and your client secret) uses a person's refresh token, that refresh token becomes invalid when Fitbit returns a new access token and a new refresh token for that person.

The refresh token behavior you described between your multiple stages of your app's tests is correct because Fitbit's API only sees the same client id. You should register an app for each of your testing environments. This will give you a client id for each testing environment. Your test user will authorize each client id and then have an access token and refresh token pair for each of your testing environments so that no single environment conflicts the others.

[sachins]

If we fail to store updated refresh token sent by fitbit servers, how long will the old refresh token be valid?

I can see situation where, we made an access token refresh request, Fitbit servers sent us new access token as well as new refresh token, but due to some server errror / network issue we failed to store it. 

@SunsetRunner

[AndrewFitbit]

@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]

So in case refresh token invalidated, then what should be done at app side?