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.

[JeremiahFitbit · Accepted solution]

OAuth 1.0a support will be removed at 10 AM PDT (UTC-7).

[chrisfou]

Lets hope my app updates work as despite emailing each time I get a

'Your app is still using oAuth1.0a' email to find out numbers to see if it's just a few people that have failed to update or I have done something wrong I never got a response.

[DavidSFitbit]

@chrisfou did you open a private support case with us? I'm not seeing any cases for you through our support channel.

[chrisfou]

I replied to the emails.

I did get one response asking for the client ID signed

'Sincerely,

James L and the Fitbit Team'

But never heard a thing after I replied with it.

I have tested my apps and they work so I guess I did it correctly, I also installed old versions of the apps before I updated and they fail so all is good for me.

[todd.trimble]

For the sake of clarity...is the migration flow now gone? Is currently expected behavior that the endpoint returns "{"errorType":"invalid_grant","message":"Refresh token invalid:..." for all refresh attempts?

Thanks for any clarification.

[aiv]

I'm in the same case as todd , is it now impossible to upgrade the tokens?

Thanks in advance!

[JeremiahFitbit]

@todd.trimble @aiv: The OAuth 1.0a to OAuth 2.0 token upgrade flow is still active.

Are you able to upgrade other users' access token and access tokens secrets? If so, perhaps the error your receiving is for a user who has revoked permission to your app.

[todd.trimble]

>> Are you able to upgrade other users' access token and access tokens

>> secrets? If so, perhaps the error your receiving is for a user who has

>> revoked permission to your app.

No. We tried several that we know are not revoked.

Good to know that the rumors of the migration path's death have been greatly exaggerated. We'll try again and reach out with more specifics when we have them.

Thanks!

[EugenMamaev]

Hi, Jeremiah.

We use Fitbit web api on our Webserver. We made the switch to OAuth 2.0. But now we have some troubles. When new user connected to our server, all works fine. But when we try update our users with this:

curl -sS \
-H "Authorization: Basic $basic_token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-X POST --data 'grant_type=refresh_token&refresh_token=$access_token:$access_token_secret&expires_in=31536000' "https://api.fitbit.com/oauth2/token"

We have this error.

{"errors":[{"errorType":"invalid_client","message":"Invalid authorization header. Client secret invalid. Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."}],"success":false}

And we had no any subscriptions when users make activity on fitbit.
Thanks for any clarification.

[aiv]

Solved! I was not doing the process properly, thanks for the support! 🙂

[todd.trimble]

Update (because you'll get info here much faster than from the Fitbit Support email):

We were able to solve our problem with Oauth1->OAuth2 migration. It turns out that '{"errorType":"invalid_grant","message":"Refresh token invalid:...' can _also_ mean that the crafted "[token]:[secret]" refresh token does not match the supplied "[client_id]:[client_secret]" encoded in the Authorization header. Maybe not the most clearly stated error message ever.

We had been trying our experiments with production tokens but using our test app's client_id and client_secret.

After correcting that, we successfully migrated 100+ tokens last Friday evening. If you're still having problems, check that.

[JeremiahFitbit]

Explanation for why it might not be the "most clearly stated error message ever":

If you supply an access token for a user of an application they didn't authorize, that access token is indeed invalid. It would not be appropriate for Fitbit to reveal that it is a valid access token for another application. It'd be like you using the wrong password and Fitbit telling you that it's not the correct password for you, but it is so-and-so's password.

[nmedina]

Hey @JeremiahFitbit

Is there an alternative way to migrate Oauth1 tokens to Oauth2 ? or was the discontinued custom OAuth 1.0a-to-OAuth 2.0 flow the only way? Are there any alternative right now to get older users over to Oauth2 without having them to reconnect their device?

Thanks,

Naz

[JeremiahFitbit]

@nmedina: OAuth 1.0a support was removed on August 1 and documentation for it was removed a couple weeks ago. The OAuth 1.0a-to-2.0 flow should still work for now, but it will be removed soon. You can find an archive of that documentation at https://web.archive.org/web/20160126164103/https://dev.fitbit.com/docs/oauth2/#migrating-from-oauth-...

Out of curiosity, why the delay in upgrading?