Refresh Token used multiple times

[alexperto]

Hi Fitbit team,

According to the OAuth2 documentation " A refresh token does not expire until it is used. A refresh token can only be used once, as a new refresh token is returned with the new access token." (https://dev.fitbit.com/build/reference/web-api/oauth2/#refreshing-tokens)

However I recently noticed that I can re-use a refresh-token multiple times and issue a new access token successfully. Based on my experiment the refresh-token is valid as long as I don't use the one that is returned in the API response.

What I've been doing so far is what I think it's the natural OAuth2 flow: whenever I issue a new token I save both the access_token and the new refresh token in my DB, but based on this finding it seems like I can just keep using the same refresh-token "forever" ???

I'm attaching 2 images demonstrating that using the same refresh-token with a difference of 5 minutes I'm able to obtain a new access_token

I'd appreciate if you could help me to understand this better

Thanks

[tparsnick]

Hi fitbit support,

Understanding the current "expiration/revoke" policy for your refresh tokens is VERY important to us.  There do seem to be differences with tested behavior and the documentation you provide as @alexperto indicates above.

We recently had a setback where about 5k "access tokens" turned  invalid  on Jan13th  and we were only able to refresh half of them.   For those that did not refresh we received 400 errors.  

The Oauth 2.0 RFC https://tools.ietf.org/html/rfc6749#section-6 says:
The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client.  

Since it says "MAY", there is no requirement that the old refresh token should be revoked.  It would be ideal if the refresh tokens were never revoked except for the case when the client(user) intentionally revokes and removes oauth authorization.

[JohnFitbit · Accepted solution]

Hi @alexperto,

A refresh token doesn't expire until the new access token obtained from it was executed in an API call. When the new access token has been used, the refresh token that was used to obtain it automatically expires. For example:

1. Access Token 1 expires. Refresh Token 1 is used to obtain Access Token 2 and Refresh Token 2.
2. Access Token 2 is not yet used in an API call, therefore Refresh Token 1 is still active.
   1. Your application executes Access Token 2 in the authorization header of Get Daily Activity Summary endpoint. This action automatically expires Refresh Token 1, therefore it is used. 
   2. Your application stores Refresh Token 2 and discards Refresh Token 1 because it is now invalid.
3. Access Token 2 expires. Refresh Token 2 is used to obtain Access Token 3 and Refresh Token 3.
   1. Your application executes Access Token 3 in the authorization header of Get Daily Activity Summary endpoint. This action automatically expires Refresh Token 2. therefore it is used. 
   2. Your application stores Refresh Token 3 and discards Refresh Token 2 because it is now invalid.

In the screenshot you provided, you executed a refresh token (we'll call 1) twice, one at 21:17:26 and the second call at 21:22:30. Since you didn't use access token 2 after your refresh attempt, refresh token 1 is still valid, which is why you were still able to execute it again at 21:22:30. Also, notice that in your second refresh attempt, you received Access Token 3 instead of Access Token 2. This occurs because Access Token 2 was not used within two minutes from it being provided. After two minutes, a new access token will be returned if the request was attempted again (Documentation).

@tparsnick Welcome to the forums! The section referenced is incomplete:

"The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the refresh token scope MUST be identical to that of the refresh token included by the client in the
request."

Using @alexperto's scenario to address your question, the application executed refresh token 1 to obtain access token 2 and refresh token 2. Since the application did not use access token 2 at this time, the authorization server chose not to revoke refresh token 1 as it is still active. When access token 2 is finally executed in a call, the authorization server chose to replace refresh token 1 because it is now used (expired), with the new active refresh token 2.

As a reminder, a refresh token can only be used once, (the act of using the new access token obtained from the request, in a call), so the choice of whether to revoke an old expired refresh token does not apply to this scenario.

I hope this helps clear things up. Please let me know if you need additional clarification.

[alexperto]

Thank you @JohnFitbit that was a great clarification.