04-01-2016 05:21
04-01-2016 05:21
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
Answered! Go to the Best Answer.
04-01-2016 09:26
04-01-2016 09:26
@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.
04-01-2016 05:41
04-01-2016 05:41
04-01-2016 05:48
04-01-2016 05:48
Hello,
In my case, I get a HTTP 400 error while invoking the access token service.
04-01-2016 06:08
04-01-2016 06:08
well well well, i just noticed that all my access codes are suffixed with "#success".
It is probably the issue.
04-01-2016 06:24
04-01-2016 06:24
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.
04-01-2016 09:26
04-01-2016 09:26
@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.
04-01-2016 09:30 - edited 04-01-2016 09:31
04-01-2016 09:30 - edited 04-01-2016 09:31
@OlivierS: The URI fragment is never sent to a server. Are you getting the 'code' value client side?
04-01-2016 09:55
04-01-2016 09:55
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 ?
04-01-2016 12:51
04-01-2016 12:51
Why do you have the Authorization Page redirect to your native app instead of directly to your webserver?
04-01-2016 13:14
04-01-2016 13:14
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 ?
04-01-2016 13:34 - edited 04-01-2016 13:34
04-01-2016 13:34 - edited 04-01-2016 13:34
This flow is more typical:
04-01-2016 13:42
04-01-2016 13:42
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?
04-01-2016 14:20
04-01-2016 14:20
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.
04-12-2016 05:34
04-12-2016 05:34
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,
07-19-2016 17:23
07-19-2016 17:23
Hi,
I am trying the following:
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.
09-20-2016 17:13
09-20-2016 17:13
I'm having the same problem. I've even just followed the flow from within the interactive oauth webpage with the same results.
09-20-2016 17:19
09-20-2016 17:19
@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.
09-21-2016 09:48
09-21-2016 09:48
09-21-2016 11:09
09-21-2016 11:09
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.
09-21-2016 13:12
09-21-2016 13:12
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.