OAuth 2.0 beta is here!

[JeremiahFitbit]

2015-10-12 UPDATE: OAuth 2.0 is now out of beta. Read more here.

Below is the original beta topic.

——————————

Today, we're excited to open access to the Fitbit OAuth 2.0 beta. All applications are now able to use OAuth 2.0 for user authorization. Documentation on using and upgrading to OAuth 2.0 is available here.

Very Important Note

During this beta period, Fitbit may need to make backwards incompatible changes with less than 30 days notice. Fitbit does NOT recommend using OAuth 2.0 in a production environment yet.

With your help testing, we hope to resolve any issues over the next few months. When we believe it is production ready, we will update this post.

How to report issues and get help

Please use the Fitbit Web API support forum. First, search to see if the issue has already been reported. If it hasn't been, create a new topic and use the "OAuth 2.0" label.

Please do not reply to this post unless you have a question or comment specific to this announcement so that others can more easily find answers.

Endpoint Updates

• Heart Rate now available in daily and intraday time series (OAuth 2.0 required)
• Get Activity TCX (OAuth 2.0 required)

Moderator edit: links

[SunsetRunner]

---

@freeubi wrote:

Are there any chances that it will be available in the next 2 weeks?

---

I'm happy to say its live!

[sbarrier]

Just to clarify, are you saying that the OAuth 2 API is now live?

[freeubi]

Wow, awesome!

[freeubi]

No,

just the mobile friendly OAuth 2.0 login webpage.

[JeremiahFitbit]

The Implicit Grant flow is now available! Updated documentation is available at https://wiki.fitbit.com/display/API/OAuth+2.0

This is the flow that distributed apps (such as mobile and native web apps) should use.

You'll need to update your OAuth 2.0 Application Type to Client in your application settings at dev.fitbit.com to use this authorization flow.

[chandrasekhar]

I Successfully Implemented the authorization step and i got the code value with redirect_uri. and while Implementing FitBit OAuth AccessToken Request (https://wiki.fitbit.com/display/API/OAuth+2.0) i am getting the following error:

WARN : org.apache.http.impl.client.DefaultHttpClient - Authentication error: Unable to respond to any of these challenges: {oauth=WWW-Authenticate: OAuth realm="https%3A%2F%2Fapi008-g4.prod.dal05.fitbit.com"}
{"errors":[{"errorType":"oauth","fieldName":"n/a","message":"invalid_request, Missing grant_type parameter value"}],"success":false}

as per document i supplied every recommended values and the code is like:

String authString = fitbit.getClient_id()+":"+fitbit.getClient_secret();
String authEncString = Base64.getEncoder().encodeToString(authString.getBytes());
String url3 = fitbit.getAccesstoken_uri();

HttpClient httpClient = new DefaultHttpClient();
HttpGet request = new HttpGet(url3);
request.addHeader("Authorization", "Basic " + authEncString);
request.addHeader("Content-Type","application/x-www-form-urlencoded");
request.addHeader("code", code);
request.addHeader("grant_type",fitbit.getGrant_type());
request.addHeader("client_id", fitbit.getClient_id());
request.addHeader("redirect_uri", fitbit.getRedirect_url());

    HttpResponse response = httpClient.execute(request);

    String json = EntityUtils.toString(response.getEntity(), "UTF-8");

Here, grant_type value is authorization_code

Accesstoken_uri : https://api.fitbit.com/oauth2/token

Can any one solve this?

[ejain]

HttpClient httpClient = new DefaultHttpClient(); HttpGet request = new HttpGet(url3); request.addHeader("Authorization", "Basic " + authEncString); request.addHeader("Content-Type","application/x-www-form-urlencoded"); request.addHeader("code", code); request.addHeader("grant_type",fitbit.getGrant_type()); request.addHeader("client_id", fitbit.getClient_id()); request.addHeader("redirect_uri", fitbit.getRedirect_url());

"code", "grant_type" etc are body parameters, not headers.

[ThatOneCat]

Any idea when this will exit beta?

[JeremiahFitbit]

---

@ThatOneCat wrote:
Any idea when this will exit beta?

---

Since mid-July, OAuth 2.0 has been considered a stable beta. During this stage, Fitbit may still need to make backwards incompatible changes with less than 30 days notice. It's production ready, but the possibility of needing to make a swift change to your integration exists. We hope OAuth 2.0 can exit beta in the next couple of months. Feedback from people using OAuth 2.0 at this stage will help us feel more confident in removing the beta label.

[mangolassi]

syntax to retrieve activity data in auth2

GET /1/user/228TQ4/activities/date/2010-02-25.json

GET /1/user/223XR3/activities/date/2010-03-27.xml

GET /1/user/-/activities/date/2010-02-21.json

GET /1/user/-/activities/date/2010-03-27.xml

[Jaiyo]

Great, thanks for the update. Any ideas on when it might exit stable beta?

[ThatOneCat]

Is it ok to show the auth page in a uiviewcontroller on iOS?

[ejain]

---

@ThatOneCat wrote:
Is it ok to show the auth page in a uiviewcontroller on iOS?

---

That kind of defeats the purpose of OAuth (not having to trust you with my username and password), but it's often done that way...

[sbarrier]

We have a large wellness program that we want to roll out beginning on October 1. This will include the purchase of hundreds of Charge HR's. 

However, we need the FB API to be finalized in order for the wellness vendor to work with it. Here's our question: when can we realistically expect that this oAuth 2 API will be finalized and available?

[JeremiahFitbit]

---

@sbarrier wrote:

when can we realistically expect that this oAuth 2 API will be finalized and available?

---

Don't get hung up on the 'beta' label. OAuth 2.0 is available today. Fitbit has been using it in several of its own services at massive scale for months. The only known backwards incompatible change coming is the removal of the default scope list. As long as your application requests the scope it actually needs (and does not rely on the current default set being automatically included), then you should be fine.

[JeremiahFitbit]

---

@ThatOneCat wrote:
Is it ok to show the auth page in a uiviewcontroller on iOS?

---

No. From the documentation:

Warning: Never Embed The Authorization Page

The OAuth 2.0 authorization page must be presented in a dedicated browser view. For native applications, this means opening the default browser. For Web applications, this means not using an iframe. Any attempt to embed the OAuth 2.0 authentication page will result in your application being banned from the Fitbit API.

This is an important security consideration. Fitbit users can only confirm they are authenticating with the genuine Fitbit.com site if they have they have the tools provided by the browser, such as the URL bar and TLS certificate information.

Native applications may use custom URL schemes as callback URIs to redirect the user back from the browser to the application requesting permission.

Web applications may use a pop-up window, so long as the URL bar is visible.

[RickGregory]

---

@JeremiahFitbit wrote:

---

@ThatOneCat wrote:
Is it ok to show the auth page in a uiviewcontroller on iOS?

---

No. From the documentation:

Warning: Never Embed The Authorization Page

The OAuth 2.0 authorization page must be presented in a dedicated browser view. For native applications, this means opening the default browser. For Web applications, this means not using an iframe. Any attempt to embed the OAuth 2.0 authentication page will result in your application being banned from the Fitbit API.

This is an important security consideration. Fitbit users can only confirm they are authenticating with the genuine Fitbit.com site if they have they have the tools provided by the browser, such as the URL bar and TLS certificate information.

Native applications may use custom URL schemes as callback URIs to redirect the user back from the browser to the application requesting permission.

Web applications may use a pop-up window, so long as the URL bar is visible.

---

The FitBit Windows 10 app seems to embed the authentication in the app. Am I missing something in the warning? - Thank you.

[JeremiahFitbit]

---

@RickGregory wrote:
The FitBit Windows 10 app seems to embed the authentication in the app. Am I missing something in the warning? - Thank you.

---

Fitbit's own native client apps are permitted to use a different authentication flow, as Fitbit controls the source code, security review, and release. Fitbit has no incentive to phish its own users.

[RickGregory]

---

@JeremiahFitbit wrote:

Fitbit's own native client apps are permitted to use a different authentication flow, as Fitbit controls the source code, security review, and release. Fitbit has no incentive to phish its own users.

---

Neither are all developers are out to phish Fitbit users. A great user experience does not include shelling out to a browser. Perhaps a certification process or a more rigid API access agreement could be found to foster the alternative auth flow.

[ThatOneCat]

We have an app that has been rejected by Apple due to the redirecting to safari for auth. After going through 3 people we have a phone call on Monday with a lead of the app reviewers to see if they will allow it. Just an FYI.