FitBit - WebAPI - Integration Models

[adrianbontea]

Hi all,

I am looking to build a new software product for the Hotel Industry. (currently in an MVP prerequisites phase) This new solution would use multiple data layers (some of which are optional) in order to build a deeper insight into the guest's overall experience for the general purpose of engaging both the hotel business and the guest in collaborating to improve the current and future experiences. (for the same guest and others from the same market segment)

One of these optional data layers that my system would collect and use is the biometrics layer: heart rate, temperature, respiration, sleep score, stress level etc.

As I am currently evaluating the FitBit solution (devices and Web API) for handling the biometric data layer collection, I have a question about the integration model:

Reading the FitBit Authorisation guide (https://dev.fitbit.com/build/reference/web-api/developer-guide/authorization/) it looks like my system would have to redirect the end user to FitBit (via a browser when using a web app or e.g. SFSafariViewController if handled from a mobile iOS app), they will have to login/signup for a FitBit account then provide the consent for my registered application to use required data fields. (OAuth 2 Authorisation Code Grant Flow)

However I am wondering if a different integration/authorisation model is possible such as:

- The FitBit tracking devices will not be owned by my system's end users but rather by my company and, as a result, just lend to end users (hotel guests) for the duration of the stay.

- This implies that the actual FitBit user for all the registered devices will be my company account.

- My system will provide an explicit terms of service and privacy policy to end users, and will obtain an explicit user consent regarding how their data is being collected, processed and shared (anonymously shared with FitBit under the facade of my product account)

- This all implies that my system should not need to redirect each end user to FitBit, require them to setup their own FitBit account grant my application to access their required data field since everything will be managed by my system.

I guess the whole question boils down to whether a system can use an alternate OAuth2 authorisation code such as Client Credentials for integrating with Fitbit Web API, rather than the recommended Authorisation Code Grant Flow.

Any thoughts much appreciated!

[adrianbontea]

Hi all,

I am looking to build a new software product for the Hotel Industry. (currently in an MVP prerequisites phase) This new solution would use multiple data layers (some of which are optional) in order to build a deeper insight into the guest's overall experience for the general purpose of engaging both the hotel business and the guest in collaborating to improve the current and future experiences. (for the same guest and others from the same market segment)

One of these optional data layers that my system would collect and use is the biometrics layer: heart rate, temperature, respiration, sleep score, stress level etc.

As I am currently evaluating the FitBit solution (devices and Web API) for handling the biometric data layer collection, I have a question about the integration model:

Reading the FitBit Authorisation guide (https://dev.fitbit.com/build/reference/web-api/developer-guide/authorization/) it looks like my system would have to redirect the end user to FitBit (via a browser when using a web app or e.g. SFSafariViewController if handled from a mobile iOS app), they will have to login/signup for a FitBit account then provide the consent for my registered application to use required data fields. (OAuth 2 Authorisation Code Grant Flow)

However I am wondering if a different integration/authorisation model is possible such as:

- The FitBit tracking devices will not be owned by my system's end users but rather by my company and, as a result, just lend to end users (hotel guests) for the duration of the stay.

- This implies that the actual FitBit user for all the registered devices will be my company account.

- My system will provide an explicit terms of service and privacy policy to end users, and will obtain an explicit user consent regarding how their data is being collected, processed and shared (anonymously shared with FitBit under the facade of my product account)

- This all implies that my system should not need to redirect each end user to FitBit, require them to setup their own FitBit account grant my application to access their required data field since everything will be managed by my system.

I guess the whole question boils down to whether a system can use an alternate OAuth2 authorisation code such as Client Credentials for integrating with Fitbit Web API, rather than the recommended Authorisation Code Grant Flow.

[adrianbontea]

Sorry, just realised this is the SDK Development section, I will move this topic to Web API development.

[GordonFitbit · Accepted solution]

Hi @adrianbontea 

The Fitbit Web API only support 2 authorization flows for collecting user data, Authorization Code Grant Flow and Implicit Grant Flow.  Authorization Code Grant Flow is recommended because it is the most secure against man in the middle attacks.   To get accurate results, you will want each user to create their own Fitbit account and supply accurate information in their profile.   Many of our algorithms use the person's height, weight, gender, etc when calculating the results.  As long as your application does not request the "profile" scope, the user should be anonymous to your application.  The only identifier your application receives is the user's Fitbit user id.

[adrianbontea]

Thanks @GordonFitbit! Makes sense...I will consider this model in my HLD. The only drawback I currently see is that my end users (temporary hotel guests) will be required to signup for a new FitBit account if they don't have one already and temporarily link the FitBit wearable device (which in my initial vision will be owned by my company) to their own account...My system would then ask the user for the required permissions on the data fields from their account, based on web redirects.

I am also considering other solutions like platforms that can setup connections to a wider range of wearable devices and services (Garmin, FitBit, Apple Health, Google Health etc) and expose the data via a uniform API. This model would actually be more convenient and cost effective since will only onboard end users who already own a wearable device (from various brands), using their existing devices and accounts...