OAuth2 authorization code flow - All my access codes seems to be invalid

[OlivierS]

Hello,

I'm experiencing some problems to get access tokens since this morning (OAuth2 authorization code grant flow, after getting the access code) : All my authorization code seems to be invalid.

I tried with 2 differents fitbit users to obtain access tokens several times using https://api.fitbit.com/oauth2/token and i'm getting this error :

{"errors":[{"errorType":"invalid_grant","message":"Authorization code invalid: 3e14c4756d3f4b6d5ed4340b7d19ffc60e14fbf8#success Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."}],"success":false}

(All was fine yesterday, some users authenticated using this flow without any problems, according to my logs).

Is there an global issue on the process ? Everything was working fine since several weeks and i did not change a single line of code.

I can post more informations in case of this is not a global issue on the service.

Thanks in advance

[GaryBrittain]

Same issue here, I'm getting status 503 Temporarily Unavailable 😞 It was working OK about 6 hours ago.

[OlivierS]

Hello,

In my case, I get a HTTP 400 error while invoking the access token service.

[OlivierS]

well well well, i just noticed that all my access codes are suffixed with "#success".

It is probably the issue.

[OlivierS]

This is the issue.

After authenticating on the fitbit webpage, my callback url is now :

http://logincallback?state=ba71e7df-f151-4a24-8b7e-19767e575fb5&code=16c5092d8296xxxxxxx74360017dad9080cf#success

the issue is that the parameter code is now appended with "#success".

I checked my app logs, this behaviour has appeared yesterday only.

By removing this part of the code, i'm able to get my access tokens again.

[JeremiahFitbit · Accepted solution]

@OlivierS: Yes, we recently started adding a URI fragment to the redirect URI in order to mitigate against a security issue related to how browsers carry URI fragments across redirects. I'm sorry that this broke your app. It's still a valid URI and I recommend using an RFC 3986 compliant URI parser to extract values from the redirect URI instead of string matching, which is more fragile.

[JeremiahFitbit]

@OlivierS: The URI fragment is never sent to a server. Are you getting the 'code' value client side?

[OlivierS]

It's a native Android app.

The process i'm using is the following :

-the user starts the android app and request to authenticate

-the web browser (native browser or chrome custom tabs) opens for login (fitbit login page).

-the redirect uri is a custom url scheme that is opened locally by my app.

-the callback containing the authentication code fires my app back.

-the code is extracted from the callback sent to my web server by a secured rest service.

-the access token and refresh token are obtained server side from the fitbit access token service (with my app id and secret) and stored server side.

Is there a problem with this process ?

[JeremiahFitbit]

Why do you have the Authorization Page redirect to your native app instead of directly to your webserver?

[OlivierS]

I need to go back to my app (launch an activity) after the fitbit login page.

By setting a custom url scheme and a local redirect like redirect_uri=myapp://logincallback?code=XXXX, my app regains control of the the flow.

The activity that receive the callback just forward the oauth2 code to my webserver.

What's the problem with that ?

[JeremiahFitbit]

This flow is more typical:

1. Your native app opens the Authorization Page
2. Fitbit redirects the user to your webserver, which does the code exchange
3. Your webserver redirects back to your native app using your custom URI scheme containing the Fitbit access token

[OlivierS]

Thanks for your really quick answer. 

That was my 2nd idea indeed, but i didn't implement that.

I can change it, but i don't see a major difference. Do you?

[JeremiahFitbit]

The main advantage is that it'd be easier to add validation logic (did the person actually give you all of the scope that you requested?) or guarantee the code-to-access token exchange is successful.

[SlavaP]

Hi Jeremiah, 

In our case, we can not pass response to our web-server application, because it use Rest approach and parameters are pass in the uri, as path variables, as far as I know fitbit support only one redirect_uri per application.
We also faced with #success problem, but on iOS platform, can we pass any additional parameter that will replace this postfix?
Thanks in advance,

[namy]

Hi,

I am trying the following:

1. My native app opens the Authorization Page
2. Fitbit redirects the user to your webserver, which does the code exchange and then it should return back to my app. I have added redirect url when I call fitbit login page.

I get succesfully redirected to fitbit login page then it goes through multiple redirects and lands to a page with already_redirected=true_#_ and never calls back my redirect url.

What could be the problem here?

Thanks.

[welbe]

I'm having the same problem. I've even just followed the flow from within the interactive oauth webpage with the same results.

[JeremiahFitbit]

@welbe: Please describe the HTTP requests being made, where they are being made (Web browser, Web server, native app, etc) and the responses you're receiving.

[welbe]

In Chrome I'll open https://dev.fitbit.com/apps/oauthinteractivetutorial and select the following:

Flow type: Authorization code flow

Oauth2 Client Id: [My id] (You can see it in the URLs below)

Client Secret: [My Secret]


I leave everything else alone.


I'll open chrome (Incognito) and go to (my app page that starts the process): http://lvh.me:3000/auth/fitbit_oauth2

My app redirects the the browser to something like: https://www.fitbit.com/login?redirect=%2Foauth2%2Fauthorize%3Fclient_id%3D228XDP%26redirect_uri%3Dht...

I log in, click authorize and I'm redirected to the following URL: http://lvh.me:3000/auth/fitbit_oauth2/callback?code=8403c5cc4fe9cd52ce8267bb93e723abc0595289&state=0...


I'll copy the 'code' portion of the URL into code part of the form on https://dev.fitbit.com/apps/oauthinteractivetutorial

I then check the generated cURL to make sure it has the correct code, then I'll copy the cURL into my terminal, checking again to make sure the code is the same and then hit enter.

Then I get something like the following:

{"errors":[{"errorType":"invalid_grant","message":"Authorization code invalid: 8403c5cc4fe9cd52ce8267bb93e723abc0595289 Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."}],"success":false}

I also get the same result if I'm calling into fitbit directly from within my application.

I've double checked the client id in the app and the client secret just to make sure the codes in both are the same. They are. I'm not sure what I'm missing.

Thanks

[welbe]

I've narrowed down the variables.

Apparently if the first fitbit URL contains my redirect_url then I get an invalid code. If it just has '' then the parameter is ignored and I get a valid code.

[JeremiahFitbit]

If a redirect_uri is specified in the Authorization Page URL, it must be specified again when you do the Access Token Request.

While optional, you are strongly encouraged to specify the redirect_uri as a best practice.