Fitbit API Returning 403 for Subscriptions

[davedickinson]

Hi

I am working on a project that utilises the Fitbit API, with OAuth2 - all has gone well up until now, but i have hit a snag with regards to the subscription api that only presents itself in certain circumstances.

As part of the  OAuth 2.0 Authorization Code Grant flow, when a user registers on our test site they are presented with an authorization page that lists all of the scopes the site requires access to.

For the time being the site requests access to all scopes (i will come back to this later on).

The scopes on the authorization page are all ticked by default,  If a user leaves all scopes ticked and grants access to the site, everything works as intended and i am able to create a subscription to the user activity scope, so that the site notification endpoint is notified of activity data updates for the subscribed user.

If the user unticks any unrequired scopes on the authorizarion page (such as the heartrate scope) then the site is still able to create a subscription for that user to the activity scope - or at least it appears that this is the case, as it returns a sucess response. However any subsequent calls to the Fitbit API to see what subscriptions a user has are responded with  a 403 forbidden response which suggests the subscription has not been succesful?

I spotted a note in the Web API documentation that says:

Note: For the OAuth 2.0 Beta Program, the activity, nutrition, profile, settings, sleep, social, and weight are required scopes and are equivalent to OAuth 1.0a access. If you do not specify these scopes, they will be appended to the list your application specifies. Fitbit is still updating all existing endpoints to support the relevant scopes. A scope will be removed from the required list when all related endpoints are updated. All scopes will be optional in the future.

From what i have observed it looks as though when a user deselects any scopes that appear to be unrelated to the subscription / activity data, such as sleep, nutrition, social,  then the subscription API calls do not appear to work as intended - with the user not having correct access to the endpoints? 

Likewise if i restrict the scopes that the site initially requires to activity, profile and settings then the subscription API calls do not work as intended.

Even if i reauthenticate the user by presenting them with a fresh authentication page with the full list of scopes and they keep them all ticked it does not alter the behavior and they are still prevented from subscribing / listing subscriptions.

Weirdly in each of these cases the user is able to make requests to the Fitbit API for other data such as activity / steps etc without issue, it is only the subscription / notification that seems to be causing an issue.

Unfortunatelty this is the main way by which our site is configured to obtain user data (when we are notified of an update to user data - we then make a separate request for it) 

Is this because scopes that appear unrequired are actually required at the current time as part of the OAuth 2 beta Fitbit implementatin and should not be left unticked / un requested.?

Thanks

Dave Dickinson

[JeremiahFitbit]

---

davedickinson wrote:

I spotted a note in the Web API documentation that says:

Note: For the OAuth 2.0 Beta Program, the activity, nutrition, profile, settings, sleep, social, and weight are required scopes and are equivalent to OAuth 1.0a access. If you do not specify these scopes, they will be appended to the list your application specifies. Fitbit is still updating all existing endpoints to support the relevant scopes. A scope will be removed from the required list when all related endpoints are updated. All scopes will be optional in the future.

---

The OAuth 2.0 beta period ended in October. I have updated this oversight in the documation. If someone unchecks a scope, that scope is not granted.

[davedickinson]

Hi

Thankyou for the swift response and for clarifying about the OAuth2 authentication process / scopes.

Based on your comment i have taken another look at the OAuth2 registration process between our site and fitbit via the fitbit API and still think there may be an underlying issue that i dont fully understand and i would be grateful if you could assist.

Following on from my previous comments about a users subscriptions not being returned via the get subscriptions Fitbit API call (if anything other than all scopes are granted access to upon registration).

After further investigation it does appear as though the subscription is sucessfully registered with fitbit (this is achieved on our site upon account creation), as i am receiving activity update notifications for the user via my end point and am processing these sucessfully, however if i request a list of the subscriptions allocated to that user i receive a 403 error and am unable to see them.

I was looking at the list of subscriptions to verify success / failure during user registration. If there was no subscription listed, i deemed there to be an issue.

At the end of the project i hope to unsubscribe the users subscriptions, however if i cannot see what subscriptions they have, i am unable to do this.

Is there something i am missing?

Thanks

Dave Dickinson

[JeremiahFitbit]

Can you please share the exact HTTP request and response that you making to get the list of subscriptions? This endpoint is documented here.