Wrong OAuth 1.0 Implementation (Token and Secrets being reused)

[FedericoArg]

We noticed that during the last couple of weeks Fitbit is generating or re-using the same Access Token and Token Secret when users connect their Fitbit account.

If I correctly understand the OAuth 1.0 implementation this should never be the case and a new pair of Token and Secret should be generated when the user authorize the access to their account.

Could someone from Fitbit confirm this issue or explain in detail why this can happen?

[JeremiahFitbit · Accepted solution]

The behavior is not specified in the OAuth 1.0a RFC. Fitbit has issued a new access token and token secret on each authorization since April 2014. This is the behavior you should expect.

We have momentarily stopped this behavior as we work on OAuth 2. You should assume that we will return to the previous behavior and your application should always update the access token and token secret at the end of an OAuth authorization.

[FedericoArg]

Can you please explain with more details what «We have momentarily stopped this behavior as we work on OAuth 2» means?

Should we expect to receive previously generated token and secret from now on?

We need to understand how the OAuth process work to accommodate everything on our end.

Thank you.

[JeremiahFitbit]

---

@FedericoArg wrote:
Can you please explain with more details what «We have momentarily stopped this behavior as we work on OAuth 2» means?

Should we expect to receive previously generated token and secret from now on?

---

Your app should always store the the token and secret the Fitbit API returns. Sometimes it will be the same token and secret that have been given for the user before. Sometimes it will be a new token and secret.

[FedericoArg]

Thanks for replying Jeremiah.

The problem of returning the same token and secret is generating problems and affecting our shared users. Returning the same token means that sometimes multiple users in our end can keep the same Fitbit account connected and sometimes they will not.

Which from my perspective doesn't seem a very predictable behavior.

What are your thoughts on this?

[FedericoArg]

We based our implementation on what you said last year

https://community.fitbit.com/t5/Web-API/Do-OAuth-1-0a-user-access-tokens-expire/m-p/324364

"Also, if a user re-authorizes your application, previously granted access tokens will be invalidated."

We expected the authorization process to follow that statement. If this changed we should have received some notification.

Thanks again

[JeremiahFitbit]

---

@FedericoArg wrote:
We expected the authorization process to follow that statement. If this changed we should have received some notification.

---

We pre-announce breaking changes. This is not a breaking change if you follow our requirement of always updating the user access token and secret.

[FedericoArg]

I think you are arbitrary assuming this is not a breaking change when in fact it is.

Scenario:

1. Peter creates User X in our app and connects his fitbit account (Access Token: AT1 - Secret: S1)

2. Peter decides he wants to create a new user account in our App, so he registers User Y

3. User Y connects the same fitbit account, expecting the other to no longer receive his information. As Fitbit is not revoking the previous access, Peter information is still being incorrectly imported into User X.

We are goint to take proper measures to deal with this scenario but this behaviour change is what I think everyone would consider a breaking change.

[JeremiahFitbit]

@FedericoArg: If you only want a 1 app user to 1 Fitbit user constraint, you should use the Fitbit user id, not the access token, to enforce this constraint.