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

[ejain]

Nice to see there's a way to exchange existing tokens!

What's the purpose of the "Basic" authorization headers? I guess there is an unwritten rule that every OAuth implementation must have at least one custom quirk 🙂

[JeremiahFitbit]

---

@ejain wrote:

Nice to see there's a way to exchange existing tokens!

What's the purpose of the "Basic" authorization headers? I guess there is an unwritten rule that every OAuth implementation must have at least one custom quirk 🙂

---

"Basic" authorization headers are the official standard way to refresh tokens.

Our "custom quirk" piggybacks on the refresh token endpoint and hopefully helps significantly ease migration. 🙂

[ejain]

Looks like this is indeed the recommended way to authenticate a client! Pardon my ignorance, this is the first time I see this in the wild (the alternate method of including the client credentials in the request body seems to be more commonly used).

[bbowden]

It may be helpful to indicate that OAuth 2 authentication is in beta on the API wiki page. I didn't realize that it wasn't production-ready until spending all day yesterday implementing it in my app (only to find an issue and open the dev forum where I discovered OAuth 2 support had existed for only a few days).

[JeremiahFitbit]

@bbowden: I have updated the documentation.

[natejgreene]

"Basic" should only be used in "Resource Owner Password Grant" https://tools.ietf.org/html/rfc6749#section-4.3  which contradicts the statement in your documentation "Fitbit currently supports the Authorization Code Grant flow."  To get the the Basic Authorization you need to have the Username and Password of the user.   Which an app would not have following the Authorization Code Grant flow.  The example in the spec illustrates a "Resource Owner Password Grant" refresh.

[ibahdanau]

---

@natejgreene wrote:

"Basic" should only be used in "Resource Owner Password Grant" https://tools.ietf.org/html/rfc6749#section-4.3  which contradicts the statement in your documentation "Fitbit currently supports the Authorization Code Grant flow."  To get the the Basic Authorization you need to have the Username and Password of the user.   Which an app would not have following the Authorization Code Grant flow.  The example in the spec illustrates a "Resource Owner Password Grant" refresh.

---

This is not true. "Basic" can be used in other flows too.

Please see 

https://tools.ietf.org/html/rfc6749#section-4.1.3

https://tools.ietf.org/html/rfc6749#section-4.4.2

[natejgreene]

Ah my mistake. It is being used for the client authentication and not user authentication and is the preferred way per the spec. This is the first service I have seen where that is required. Typically it is just passed in the request body/url over https i.e. Google. There are probably a few client libraries that do not support it.

[sbarrier]

We are trying to build a wellness solution using the Charge HR and the OAuth 2 API. Do you have any idea when this API will be out of beta?

[JeremiahFitbit]

@sbarrier: I don't have an estimate at this time. The underlying technology is fairly stable now. Fitbit itself now is using OAuth 2.0 in three production services. However, there have been minor, customer impacting issues and we may still need to make backwards incompatible changes. Most of the remaining beta issues are experiential: a sign in screen that's not mobile friendly, OAuth 1.0a scopes being required, the visual design not yet perfect.

[iatricjb]

Would you anticipate, not commit, that the beta process would take weeks and not months?

[JeremiahFitbit]

---

@iatricjb wrote:

Would you anticipate, not commit, that the beta process would take weeks and not months?

---

I anticipate that it will be months, not weeks, before OAuth 2.0 transitions from beta to our recommended method. It's fairly stable now, but there are unknown unknowns and we may need to make backwards incompatible changes faster than our usual 30 day policy. We are still working on new features, UI improvements, and bug fixes.

Fitbit itself now is using OAuth 2.0 in three production services, but we've done so with the understanding that things may break or need to change quickly.

[freeubi_tep]

There is a mobile friendly login page for the OAuth 2.0?

[JeremiahFitbit]

---

@freeubi_tep wrote:
There is a mobile friendly login page for the OAuth 2.0?

---

Not yet. It is a launch requirement, so it will be available at some point before the OAuth 2.0 beta period concludes.

[JorgeYago]

Can we use all old Oauth 1.0a scopes with Oauth 2.0?

Thanks!

[freeubi]

Thanks for your reply.

Actually i'm thinking of a temp solution:
Can I use the old OAuth 1.0a login system to get the credentials, then immediately exchange the tokens to OAuth 2.0? Then I can store them and use later.
This way I still have a mobile friendly page 🙂

[SunsetRunner]

---

@freeubi wrote:

Thanks for your reply.

Actually i'm thinking of a temp solution:
Can I use the old OAuth 1.0a login system to get the credentials, then immediately exchange the tokens to OAuth 2.0? Then I can store them and use later.
This way I still have a mobile friendly page 🙂

---

If you can wait a while longer, you won't have to jump through those hoops. We will definitely have all mobile friendly pages by the time OAuth 2.0 exits beta.

[SunsetRunner]

---

@JorgeYago wrote:

Can we use all old Oauth 1.0a scopes with Oauth 2.0?

Thanks!

---

Are you referring to when you exchange an OAuth 1.0 token for an OAuth 2.0 token, are the scopes preserved? The answer to that is yes.

[freeubi]

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