Single-time access for a specific set of data

[BrotoriousNIG]

Let me get this straight...

I want to retrieve my 15minute interval timeseries data for calories burned between two dates, and to do this I have to develop an application that implements an OAuth library, just to run it this one time to get the data I want?

I can't just supply the API authentication keys as part of the request, like other APIs do, and get my JSON back?

[JeremiahFitbit]

Apps access data on behalf of a user. A user must grant permission to the app. This is how most APIs work.

You can use OAuth 2.0 with the Implicit Grant Flow, which results in an access token after the authorization page, then throw that in the Authorization header in your HTTP request.

[BrotoriousNIG]

"Granting permission" to an "app" is simply the process of generating an API key and providing it to the app so it can supply it in its requests.  It doesn't need to be any more complex than that.  This, what we've got now, is an overengineered solution.

I should be able to put my API key into a URI, pop it into a browser address bar, and out pops the JSON.

Hell, the documentation for the resource requests even includes "/user/-/" to say that I want the data for the currently logged in user, which means your API is clearly reading session data, and since I can't log in without authorising, that should be that! Right? I'm auth'd, the session data confirms it, but no, I need to use OAuth in order to get anything out of Franz Kafka's Fitbit API.

[JeremiahFitbit]

---

@BrotoriousNIG wrote:
Hell, the documentation for the resource requests even includes "/user/-/" to say that I want the data for the currently logged in user, which means your API is clearly reading session data

---

Incorrect. The Fitbit API does not use cookies. The access token you obtain through the OAuth process is what identifies you.

[JeremiahFitbit]

---

@BrotoriousNIG wrote:

"Granting permission" to an "app" is simply the process of generating an API key and providing it to the app so it can supply it in its requests.  It doesn't need to be any more complex than that.  This, what we've got now, is an overengineered solution.

---

OAuth 2.0 is an industry standard. The vast majority of Fitbit API usage is by third-party applications, not individuals only accessing their own data. I agree that there are tools that could make individual use easier—and we're working on them—but our primary focus is on creating the best platform for Fitbit's own and third-party apps.

[BrotoriousNIG]

Just because it's an industry standard doesn't mean it's the best choice for everything for which you could possibly use it.

It is irrelevant whether the API usage is 'third-party applications' instead of individuals, as those thirdparty applications are plugging in to retrieve what, precisely, if not individuals' data?  Once you give that thirdparty app your API key, it doesn't matter whether you're using OAuth, simple key, or even biometric key - the thirdparty app has the authentication.  What do you gain in this case by using OAuth?

Speaking of which, what exactly do you envision is the process for someone providing their API details to a thirdparty application?  Right now, creating an API key for an app involves providing the name of the app, the description of the app, the website for the app, the organisation that makes the app, their website, the application type, the callback URL for the app, and whether it's read-write.  So instead of simply generating a key with a permission set and providing that key with a userID to the app, you've got to take all this information from the app provider, pop it into this form, and then provide the info back to the app.  What a palaver.

I did this yesterday, providing the API information to a Google Docs addon, and the API decided it didn't like the callback URL.  Rather than, say, trying the callback, it just rejected the URL completely.  It was a perfectly valid URL.  I replaced the Google Doc project ID in the callback URL in the Fitbit API app with just a number and it attempted the callback but obviously the Google Doc project didn't exist.  So the API had decided that it didn't like the callback URL for an unknown reason - the form of the URL hadn't changed, just part of the 'path' part of the URL.

How many users do you envisage having the patience for this, or the required understanding of the terms?  I would never dream of asking one of my users to do this.

[Michael]

@BrotoriousNIG For a third party app, you wouldn't have to do anything, the developer creates the API key on the Fitbit site, and then when you use their app it directs you to the Fitbit app for you to allow that app to access your Fitbit account/data.

If you really only need one-time access for some data have you tried using the API explorer that Fitbit has provided? (It allows you to execute API requests very simply, and again you don't have to create an API key since they have already done that, you just have to allow it access to your data.)

[JeremiahFitbit]

@BrotoriousNIG: A third-party application registers itself with https://dev.fitbit.com . It then sets up the OAuth authorization flow to obtain consent from Fitbit users. Fitbit users don't see anything but the webpage asking for permission. Fitbit users of a third-party application don't have to do anything on dev.fitbit.com or code.