Getting user's data with one access_token fails in many endpoints

[ARadmanesh]

It's intresting, based on what's been discussing for example here: [ One-application-multiple-users-data ], I had the same understanding after I've read the documentation and by the logic of OAuth and scopes. But now that I have an application (Server) with Intraday access enabled and I'm in the process of development; I've experienced that for some (in fact many of them) API endpoints will return a 500 error with different error message, like You don't have sufficient access, or the user should have authorized your app to access the data. Initially I came to a conclusion that only with the access_token of the owner of the application you would have access to everyone's data, Alas I was totally wrong!
In the end, now to fetch each device data I use it's user's access token to access the API and everything works just fine now!!  It's strange, I would really like to know why this happens and if it is somehow intentional, what's the purpose and advantage of doing that?

[GordonFitbit · Accepted solution]

Hi @ARadmanesh 

Based on what you wrote in your first paragraph, you were having some difficulties with the logic of OAuth2 and how to implement it in your application.  It's difficult to say what your specific problems was based on the information you provided.   First, the HTTP Status 500 does not match the error messages you listed.  And, as you found out, the access_token for the owner of the application does NOT give you access to everyone's data.   

If you want some "light" reading, or need help sleeping, check out the spec for the OAuth 2.0 Authorization Framework referenced in our documentation.  The goal of the framework is to securely allow 3rd party application gain access to a user's data, and allow the user to have control over who has access to their data.  The access tokens contain some key pieces of information: the Fitbit user id, your application client ID and the scopes the user consented to share.  This allows each user to share a unique set of scopes for a specific application.   If consent was not implemented this way, a person's sensitive data would be at risk.  Over the years, the consent flows have improved to help prevent man-in-the-middle attacks.   The most secure authorization flow is Authorization Code Grant Flow with PKCE.  Fitbit doesn't require this, but it is highly recommended.  

Does this answer your question?

[ARadmanesh]

Thank you for clarification. Yes I had a lot of difficulties using Web API in a React app using Firebase, and using functions. The problem is all the libraries mentioned in Fitbit dev documents and tutorials are very old and don't work. Alas, I'm over it now, I've set up my own express node server on GCP which uses  Authorization Code Grant Flow with PKCE to connect with the api.

I'm no expert in security, and I didn't know the user consent scopes. I haven't fully read spec of OAuth 2.0 Authorization, just skimmed through... Just to fulfill my curiosity I'm having problem understanding why after authorization is done and the user has consented to some scopes, the access_token of the resource owner is required to be sure of the consented scope. The client is always known to the server and the server can check if the user have given his consent to the requested scope.

P.S: Should I create a thread for discussing the Authorization in React using Firebase and Google Cloud Platform?