Authorization can make refresh token invalid.

[jeaglemc]

Hello –

I don’t know if this is expected or not, or if anybody else can verify this, but I thought I would put this out there.  Basically, it seems an accidental attempt to authorize to somebody elses account invalidates that other user’s refresh token but not their one-hour access token or subscription.

Our QA guy can re-create.  Without &prompt=login consent, we see the problem quite often where two or more Fitbit users share a computer. We implemented &prompt=login consent yesterday, which we think will reduce the occurrence of our users experiencing this problem, but he checked if it could still occur if the user was forced to login to authorize our application and it did happen.

We use code grant flow.

The setup for the problem …

Jack authorized our application with his Fitbit account.  Jack has been using our system for a few days and we’ve been getting notifications for Jack and pulling his data just fine and refreshing his expired one-hour access tokens just fine.

Jack and Jill share a computer.  Jill, just now, goes to authorize our app with her Fitbit account.  She clicks our app’s button and we navigate her to Fitbit’s authorization page.  However, Jack left the shared computer logged into his Fitbit account and Jill doesn’t notice see she is logged in as Jack on the Fitbit authorization page and clicks on Allow.

Fitbit makes the callback to our app and we tell Jill that somebody else has already authorized our application with that account and she decides to try later or to contact support later or something … she just walks away.

The problem ...

After Jill’s failed attempt to authorize our app per above, we still get notifications for Jack and our one-hour access token for Jack is still good so we can pull his data.  However, when we go to refresh Jack’s access token his refresh token is not good (response code 400, per Fitbit), and we can’t get a new access token -- we still receive notifications for Jack, but we can’t pull his data until Jack re-authorizes our application and we get a new access token that way.

Kind regards.

Jay

[JeremiahFitbit · Accepted solution]

Hi Jay,

Every time a person goes through the OAuth 2 authorization proces, your app will receive a new access token and refresh token. While multiple valid access tokens can overlap in lifetime, there is only one valid refresh token. This is intentional. Your app will need to save the most recently granted refresh token for a person.

[jeaglemc]

Worded like that ... yeah, that makes sense.  Thank you for the explanation.

Like I said before, we added &prompt to the authorization URL to force login and I expect that to help us out quite a bit.  I'll also code saving the new access and refresh token to the proper user account that is received by the accidental authorization to the wrong user account.

[gwsyzygy]

@JeremiahFitbit wrote:

Hi Jay,

Every time a person goes through the OAuth 2 authorization proces, your app will receive a new access token and refresh token. While multiple valid access tokens can overlap in lifetime, there is only one valid refresh token. This is intentional. Your app will need to save the most recently granted refresh token for a person.

---

That seems to suggest that there is only one valid refresh token per ClientID + UserID, meaning an app cannot be (successfully) run on more than one device for a given user.  Is that correct (that is the behavior I am seeing).  Is there a way to get around that? 

[JeremiahFitbit]

Correct, there is only ever one valid refresh token per user of an app. To get around this, create a Web service that manages access tokens across clients or use the Implicit Grant Flow, which allows access tokens that last up to a year but requires the person to reauthorize your app when the access token expires.