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

[RickGregory]

---

@ThatOneCat wrote:
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.

---

I'd be curious to hear how that call goes. Thank you.

[ejain]

I'm guessing they are citing section 2.17 of the app store review guidelines ("Apps that browse the web must use the iOS WebKit framework and WebKit Javascript")?

Here's a good write-up of the security implications of collecting credentials through an embedded browser: https://software-security.sans.org/blog/2011/08/23/oauth-mobile-hack-password-tracking-in-malicious-... If anything, Apple should be rejecting apps that force users to trust them with 3rd-party credentials!

Those who would give up essential security to purchase a little temporary convenience, deserve neither security nor convenience 🙂

[ThatOneCat]

Actually it is section 10.6 they're concerned about. They just want a
pretty UI...

[JeremiahFitbit]

---

@RickGregory wrote:

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.

---

The alternative auth flow you're referring to involves only authenticating the user. People only have to sign in to use the Fitbit apps. There is no second authorization screen.

Fitbit provides email address/password sign in. If Fitbit permitted third-party apps to use this method, there would be nothing Fitbit could do to continously guarantee third-party developers do not intercept user credentials.

Fitbit also provides social media sign in options (Facebook and Google). There is no way technically that Fitbit could enable third-party apps to sign into Fitbit using Fitbit's Facebook and Google application credentials without Fitbit sharing its own app credentials with these services and then compromising Fitbit's and users' security.

Fitbit reserves the ability to add new sign in options in the future and the only way it can guarantee all methods are always avaialble is to control the sign in experience.

Security is fundamental to a great user experience. Fitbit is not going to allow third-party applications to use the same authentication/authoriation flow its apps use for this reason.

[JeremiahFitbit]

@ThatOneCat: That is crazy. If there is something I can do to help, please let me know. Apple's app reviewers are rather inconsistent and may not understand the security implications.

Bouncing to Safari is the only way users know for certain they are entering their username/password into a genuine Fitbit sign in form and not a form that merely looks like Fitbit's. Also, if people are already signed into Fitbit, they only have to grant permission to the app, saving time.

[ThatOneCat]

Just got off the phone with Apple. The head reviewer said that they had sent this request up the chain of command to the top and that they would not be allowing this type of authentication to happen. They said I would have to use the native webview or it won't get approved. I told them that you guys would ban the app if I did that and they said that the Fitbit devs should contact Apple to talk about it. So for now I will fall back to OAuth 1...

[JeremiahFitbit]

We are reaching out to Apple regarding their policy. Thank you for the update.

[RickGregory]

I am encouraged that FitBit is reaching out on this matter. While I secretly hope that FitBit will reconsider the requirement to shell out to a browser for auth, I am curious to the outcome of this matter.

[ThatOneCat]

Thanks for being so fast to respond and so helpful!

[JeremiahFitbit]

The documentation has been updated regarding embedded web views:

iOS applications may use the SFSafariViewController class instead of app switching to Safari. Use of the WKWebView or UIWebView class is prohibited. iOS 8 users will need to app switch to Safari.

Android applications may use Chrome Custom Tabs instead of app switching to the default browser. Use of WebView is prohibited.

[R8VXF]

Windows 10 apps? (Both phone and desktop)

[JeremiahFitbit]

@R8VXF: Microsoft does not have the flawed app review policy that Apple has regarding OAuth 2.0 authorization, so we recommend app switching to Edge as the OAuth 2.0 framework intended.

[R8VXF]

Wahaay for a reasonable company! Both you and MS on that part 🙂

Not actually come up against any companies validation policy as sql is my language of choice, but may do one day if I can get the hang of this MVC s$%t! C# unit test for ssis are good fun to write though 😄

[JeremiahFitbit]

OAuth 2.0 is now out of beta. Read more here.

[JeremiahFitbit]

Please see the updated OAuth 1.0a removal timeline.