OAuth 1.0a removal update

[JeremiahFitbit]

In October 2015, Fitbit announced OAuth 1.0a support would be removed in six months on April 12, 2016.

The Web API team at Fitbit is pleased by the quantity of applications that have upgraded to OAuth 2.0 successfully. Many apps have taken advantage of our custom OAuth 1.0a-to-OAuth 2.0 flow to upgrade user access tokens seamlessly with no end-user interaction.

We hoped sharing our OAuth 2.0 plan nearly a year in advance would give developers enough time to upgrade confidently and strategically. Unfortunately, we've received requests for a deadline extension from developers who have not yet completed their migration and are not on track to do so by April 12.

Here is our updated OAuth 1.0a removal plan:

• Starting this week, no new OAuth 1.0a client credentials will be issued.
• Existing applications will be able to use OAuth 1.0a for API requests and authorization until August 1, 2016. This is the absolute latest date OAuth 1.0a will work.
• Starting April 12, 2016, OAuth 1.0a API requests may take longer, as OAuth 2.0 requests will be prioritized.

Fitbit is committed to providing a reliable and powerful platform. We need apps serving our shared users to do their part in ensuring an uninterrupted experience.

If you need assistance, a team of Fitbit software engineers is available to help here in the Web API support forum.

[juthuppan]

Hi Jeremiah,

Can you help me understand or direct me to a document that helps explain the different purposes for OAuth 1.0a, specifically for Fitbit devices and data?  Also where can I find information about OAuth 2.0 and the differences between the 2?

Any information would be helpful.

Thanks,

Joe

[JeremiahFitbit]

@juthuppan: The data is the same. OAuth is only the means for obtaining user consent and authenticating requests. More information is here in the docs.

[Brulath]

I haven't changed anything in my application, which has been making successful requests for quite some time now, but since the first of April I've been unable to make minute data requests (400 Bad Request errors) using OAuth 1.0. Is this intended?

[gravitas1]

After April 12 will users be able authorize on the oauth1 endpoint still?

The only thing I should be concerned about is that the oauth1 endpoints will be slower, the responses of all endpoints should be the same until Oauth1 is deprecated on August 1? 

Moderator edit: merging topic

[JeremiahFitbit]

@gravitas1: OAuth 1.0a authorization flow will remain active until August 1, 2016.

[JeremiahFitbit]

@Brulath: What does the error message in the response body say?

[Brulath]

I believe it was blank, but I just implemented the oauth2 upgrade early (was going to do it around the 10th, 'cos living on the edge is where it's at). I made an oauth2 version of the fitbitphp library https://github.com/Brulath/fitbit-php-oauth2 and the web requests seem to work properly again for me with minimal changes to my code \o/.

[ShaneFitbit]

As part of our OAuth 1 migration, starting today, as mentioned earlier in this thread, no new OAuth 1 client credentials will be issued, and OAuth 1 client credentials for existing applications will not be displayed.

[jlin]

When will be the last day for the custom OAuth 1.0a-to-OAuth 2.0 flow?

[JeremiahFitbit]

---

@jlin wrote:

When will be the last day for the custom OAuth 1.0a-to-OAuth 2.0 flow?

---

@jlin: August 1 when OAuth 1.0a is finally removed.

[kostya]

---

@JeremiahFitbit wrote:

---

@jlin wrote:

When will be the last day for the custom OAuth 1.0a-to-OAuth 2.0 flow?

---

@jlin: August 1 when OAuth 1.0a is finally removed.

---

Hi Jeremiah,
What about migration of user tokens ( https://dev.fitbit.com/docs/oauth2/#migrating-from-oauth-1-0a ). Will it removed August 1 also?

[JeremiahFitbit]

@kostya: All OAuth 1.0a support, including the migration flow, will be removed on August 1.

[kostya]

Hi @JeremiahFitbit,
Thank you for the reply.
We have about 150 000 users with FitBit account. We are going to exchange their OAuth 1 tokens for OAuth 2 ones. We will make only one request per user for that. According to the documentation (https://dev.fitbit.com/docs/basics/#rate-limits) we shouldn't face any limits. Could you please confirm. Is it save for FitBit API to receive such amount of requests in some short period?

[piotr-zywien]

Dear @JeremiahFitbit,

While I reailze I am asking this question far too late, I am in a bit of a bind. I am using the fitbit4j java client API on my backend and would like to continue using it, though with an update to OAuth2 authorization (even though fitbit4j uses OAuth which will be discontinued soon). That being said, currently it is not an option to not use fitbit4j as it services integration with Fitbit devices in our app (and updating the entire integration might take longer than until August 1st). These API calls however need to be autorized with OAuth2 to continue service. Hence, until we transition fully, I would be insurmountably grateful if you were able to suggest a good way to (only for the time being) be able to continue providing our Fitbit users with service, without actually getting rid of the legacy fitbit4j API in the back end...

I realize this is an inconvenience for you, however I'd very much be indebted if you could post a suggestion which would get me out of my predicament. 

Thanks sincerely and enjoy your week! 🙂

Piotr.

[JeremiahFitbit]

@piotr-zywien: Fitbit is not going to support OAuth 1.0a beyond August 1, 2016. This change has been widely communicated and we've already extended the deadline once (from April 12th). I understand that you're behind. Fortunately, 3 weeks is still enough time to make the changes necessary.

[piotr-zywien]

Dear @JeremiahFitbit,

Thanks for your answer. I hope so. By changes necessary, do you mean
changing only the authorization part and (if possible) continuing using
fitbit4j or a full overhaul of the backend Fitbit integration?

Thanks! 🙂
Piotr.

[kotolabs]

Are we sure the migration path still works?

I can't seem to get an OAuth2 access token for OAuth1a tokens that still work - getting an "invalid_grant" error with "Refresh token invalid: ..." even though I am passing the requested "user's OAuth 1.0a access token and access token secret concatenated with a colon" and am getting them back in the error response as expected...

[JeremiahFitbit]

@kotolabs: Yes, the migration endpoint is still active. Contact us privately with the request that you're making.

[kotolabs]

@JeremiahFitbit waiting for a reply...