Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Associating Same Fitbit Account to Multiple Application Accounts

ANSWERED

[I searched but didn't see this exact issue in the forum]

Background:

If a user has a Fitbit account, then steps through the process in our app of having the user "register" that Fitbit account (via Fibit login and callback), our back-end ties the resulting credentials to that user; This is working great.

However, if the same user has or creates a 2nd account in our app, and then registers that same Fitbit account via our app to the 2nd user, an interesting thing happens: The same Fitbit user ID is returned, with a new oAuth access_token and refresh_token. This renders the access_token and refresh_token stored for the first user invalid. (As would be expected)

I have handled this by removing the tokens and Fitbit UserId from the first user (in our app-as identified by Fitbit UserId), and storing the new tokens for the 2nd user with the same Fitbit UserId (along with transferring the subscription IDs from the first to the 2nd user). This is also working fine. 

Problem Scenario:

The issue I can't seem to code around is an extension of the above: If the same Fitbit account is tied to a 2nd user in a different environment (DEV/QA/PROD). It seems that even though I have registered separate applications for each environment, the Fitbit account is given the same Fitbit UserId across all environments/registered applications, not per env/application. Therefore, if I link a Fitbit account to an app user in DEV, and then later (in QA) I link that same Fitbit account to a QA user, it renders the tokens for the user in DEV invalid. And since the 2nd (QA) registration's oAuth callback is returned to the QA app, there is no way for the DEV app to respond to remove the previous tokens as I described above. Furthermore, subscription notifications keep coming for the user in DEV, but I can no longer retrieve the data.

Is there a way to handle this scenario?

I will concede that this cross environment scenario probably wouldn't happen with end users. However, it would be nice to handle for DEV and QA as we have a limited number of Fitbit accounts to test with.

Thanks!

Best Answer
0 Votes
1 BEST ANSWER

Accepted Solutions

Hi @Jeff_New_Ocean 

 

I want to state I don't believe your scenario is unique.   There are several developers that have multiple environments and face the problem of the same user creating new accounts in their system because the user has forgotten their login or that they already registered.

 

Each Fitbit user has a single Fitbit user id that is unique to them and will not change.  It doesn't matter if the user consents to share their data with your application or another 3rd party application, both applications will receive the same Fitbit user id for this user.   It sounds like your application has its own account id which is associated with the Fitbit user id.   If so, the scenario where 2 New Ocean account ids being generated containing the same Fitbit user id does sound correct.   When the user goes through the authorization process again, the tokens are going to overwrite the existing tokens you have.

 

For the problem scenario of multiple environments, do you have different client IDs for each environment?  The access tokens are defined by the client ID, Fitbit user ID and the scopes selected.   As I stated above, you will receive the same Fitbit user id for each environment.   However, if the QA, DEV and PROD environments use different client IDs, then the access tokens for that user will also be unique to each environment.   You'll need to make certain you keep the tokens separate based on the environment.  You will not be able to use an access token from the QA environment on the PROD environment because they have 2 different client IDs.   You'll get a permissions error referencing the invalid client ID.

 

Based on the problem you're having with tokens becoming invalid and the subscriptions stop working, it's possible you're getting the user mixed up across environments and overwriting the tokens and subscriptions created.

 

Does that help?

Gordon Crenshaw
Senior Technical Solutions Consultant
Fitbit Partner Engineering & Web API Support | Google

View best answer in original post

Best Answer
4 REPLIES 4

Hi @Jeff_New_Ocean 

 

I want to state I don't believe your scenario is unique.   There are several developers that have multiple environments and face the problem of the same user creating new accounts in their system because the user has forgotten their login or that they already registered.

 

Each Fitbit user has a single Fitbit user id that is unique to them and will not change.  It doesn't matter if the user consents to share their data with your application or another 3rd party application, both applications will receive the same Fitbit user id for this user.   It sounds like your application has its own account id which is associated with the Fitbit user id.   If so, the scenario where 2 New Ocean account ids being generated containing the same Fitbit user id does sound correct.   When the user goes through the authorization process again, the tokens are going to overwrite the existing tokens you have.

 

For the problem scenario of multiple environments, do you have different client IDs for each environment?  The access tokens are defined by the client ID, Fitbit user ID and the scopes selected.   As I stated above, you will receive the same Fitbit user id for each environment.   However, if the QA, DEV and PROD environments use different client IDs, then the access tokens for that user will also be unique to each environment.   You'll need to make certain you keep the tokens separate based on the environment.  You will not be able to use an access token from the QA environment on the PROD environment because they have 2 different client IDs.   You'll get a permissions error referencing the invalid client ID.

 

Based on the problem you're having with tokens becoming invalid and the subscriptions stop working, it's possible you're getting the user mixed up across environments and overwriting the tokens and subscriptions created.

 

Does that help?

Gordon Crenshaw
Senior Technical Solutions Consultant
Fitbit Partner Engineering & Web API Support | Google
Best Answer

Thank @GordonFitbit 

We do have different client Ids for the three environments. Let me recheck the "Problem Scenario" above. It sounds like your saying if store and use the tokens separately in each environment, it should work.

Best Answer

[reply deleted as duplicate]

Best Answer
0 Votes

I confirmed that associating the same Fitbit account to accounts in different environments is NOT an issue. Both environments are able to use their respective tokens to retrieve data.

Thanks!

Best Answer
0 Votes