Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Cannot set redirect_uri to urn:ietf:wg:oauth:2.0:oob

In https://camlistore.googlesource.com/camlistore/+/master/pkg/oauthutil/oauth.go#30, I read:

 

 

// TitleBarRedirectURL is the OAuth2 redirect URL to use when the authorization
// code should be returned in the title bar of the browser, with the page text
// prompting the user to copy the code and paste it in the application.
const TitleBarRedirectURL = "urn:ietf:wg:oauth:2.0:oob"

 

 

Unfortunately, in https://dev.fitbit.com/apps/edit/228XTZ, I cannot set the Callback URL field to that — the UI says:

urn:ietf:wg:oauth:2.0:oob is not a valid URL

 

Could you please implement this part of oauth2? I’m developing a command-line application (https://github.com/stapelberg/fitbit-backup) for which an HTTP URI does not make sense.

 

Thank you.

PS: To read this post properly, you’ll want to set “Emoticon type” to “none” in https://community.fitbit.com/t5/user/myprofilepage/tab/user-preferences%3Adisplay. I couldn’t figure out how to make the forum software not auto-convert my text to emoticons :(. At least in PRE tags, I wouldn’t have expected that…
Best Answer
15 REPLIES 15

Thanks for the feedback. Currently, we don't have an OOB OAuth 2.0 flow supported. We are planning to add this feature, but I don't have a timeframe to share yet.

Best Answer
0 Votes

I'd throw my weight in support of this request. I'm doing R and R's httr lib does oob for obvious reason that it is not a Web app. Since R is the tool of choice for anyone serious enough about statistical/time-series analysis, I'd say that oob support would be a must.

Best Answer
0 Votes

R specifies "http:://localhost:1410" as redirect_uri when httpuv package is installed. So, it would be great if that is supported as well.

Best Answer
0 Votes

The easiest way to get what you're wanting at this point is for your application to listen to a port on localhost and accept the information using the HTTP callback. An application doesn't have to be a Web application to do this.

Best Answer
0 Votes

@JeremiahFitbit wrote:

The easiest way to get what you're wanting at this point is for your application to listen to a port on localhost and accept the information using the HTTP callback. An application doesn't have to be a Web application to do this.


Thanks JeremiahFitbit. But it still returns:

 

Developer information: invalid_request - Invalid redirect_uri parameter value

 

R-generated request looks like this:

 

https://www.fitbit.com/oauth2/authorize?client_id=xxx&scope=activity%20heartrate%20sleep&redirect_ur...

 

Any idea why this is not working?

Best Answer
0 Votes

@tkinsf wrote:

@JeremiahFitbit wrote:

The easiest way to get what you're wanting at this point is for your application to listen to a port on localhost and accept the information using the HTTP callback. An application doesn't have to be a Web application to do this.


Thanks JeremiahFitbit. But it still returns:

 

Developer information: invalid_request - Invalid redirect_uri parameter value

 

R-generated request looks like this:

 

https://www.fitbit.com/oauth2/authorize?client_id=xxx&scope=activity%20heartrate%20sleep&redirect_ur...

 

Any idea why this is not working?


Double check your redirect_uri setting value on dev.fitbit.com for the app in question.

You can test this out with my test app:

https://www.fitbit.com/oauth2/authorize?client_id=229RK5&scope=activity%20heartrate%20sleep&redirect...

Best Answer
0 Votes

@SunsetRunner wrote:

@tkinsf wrote:

@JeremiahFitbit wrote:

The easiest way to get what you're wanting at this point is for your application to listen to a port on localhost and accept the information using the HTTP callback. An application doesn't have to be a Web application to do this.


Thanks JeremiahFitbit. But it still returns:

 

Developer information: invalid_request - Invalid redirect_uri parameter value

 

R-generated request looks like this:

 

https://www.fitbit.com/oauth2/authorize?client_id=xxx&scope=activity%20heartrate%20sleep&redirect_uri=http%3A%2F%2Flocalhost%3A1410&response_type=code&state=K2ooLbQ7Vg

 

Any idea why this is not working?


Double check your redirect_uri setting value on dev.fitbit.com for the app in question.

You can test this out with my test app:

https://www.fitbit.com/oauth2/authorize?client_id=229RK5&scope=activity%20heartrate%20sleep&redirect_uri=http%3A%2F%2Flocalhost%3A1410&response_type=code&state=K2ooLbQ7Vg


Thanks, that works. Apologies to OP, btw, for hijacking the thread.

Best Answer
0 Votes

@tkinsf wrote:

Thanks, that works. Apologies to OP, btw, for hijacking the thread.


Well, I spoke too fast. The authentication completes fine, but invalid_request ("Authrization header required") error instread of the access token is returned. The same code works fine with github (https://github.com/hadley/httr/blob/master/demo/oauth2-github.r ), so I wonder what is different with fitbit. In case anybody can shed some light, here is what I have:

> fitbit_token<Token>
<oauth_endpoint>
 authorize: https://www.fitbit.com/oauth2/authorize
 access:    https://api.fitbit.com/oauth2/token
<oauth_app> ChronicPatient
  key:    229VPH
  secret: <hidden>
<credentials> errors, success
---
> fitbit_token$credentials$errors
$errors[[1]]
$errors[[1]]$errorType
[1] "invalid_request"

$errors[[1]]$message
[1] "Authorization header required. Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."



$success
[1] FALSE

 

Best Answer
0 Votes

Please see this section in the docs:

Access Token Request
When a user authorizes your application in the Authorization Code Grant flow, your application must exchange the authorization code for an access token. The code is only valid for 10 minutes.

Authorization Header

The Authorization header must be set to Basic followed by a space, then the Base64 encoded string of your application's client id and secret concatenated with a colon. For example, the Base64 encoded string, Y2xpZW50X2lkOmNsaWVudCBzZWNyZXQ=, is decoded as "client_id:client secret".

https://dev.fitbit.com/docs/oauth2/#access-token-request

Best Answer
0 Votes

@SunsetRunner wrote:

Please see this section in the docs:

Access Token Request
When a user authorizes your application in the Authorization Code Grant flow, your application must exchange the authorization code for an access token. The code is only valid for 10 minutes.

Authorization Header

The Authorization header must be set to Basic followed by a space, then the Base64 encoded string of your application's client id and secret concatenated with a colon. For example, the Base64 encoded string, Y2xpZW50X2lkOmNsaWVudCBzZWNyZXQ=, is decoded as "client_id:client secret".

https://dev.fitbit.com/docs/oauth2/#access-token-request


So, the only possibility I can think of, given that R works fine with google's and github's oauth2, is that R's oauth2.0_token() call passes client ID/secret as URL parameters in the request body. If that is the case, can fitbit implement the acceptance of client ID/secret in the body also? Per oauth2 rfc section 2.3.1:

 

Alternatively, the authorization server MAY support including the
   client credentials in the request-body using the following
   parameters:

   client_id
         REQUIRED.  The client identifier issued to the client during
         the registration process described by Section 2.2.

   client_secret
         REQUIRED.  The client secret.  The client MAY omit the
         parameter if the client secret is an empty string.

Best Answer
0 Votes

I opened an issue with httr project. Is there a test account they could use to reproduce the problem? I suppose they could use OAuth 2.0 Code Flow Test App, but I prefer not to give out my account for testing purpose.

Best Answer
0 Votes

I was having a similar problem and saw the issue you raised with httr on github. That really helped in coming up with a solution, so thanks @tkinsf. My pull request has now been merged into the development version of httr and provides a new "use_basic_auth" option for oauth2.0_token() to retrieve the token using HTTP Basic authentication, as required by Fitbit, rather than by providing the client ID/secret in the request body.

 

// Until a new release on CRAN, get the development version
library(devtools)
install_github('hadley/httr')
library(httr)
...
oauth2.0_token(fitbit_endpoint, myapp, use_basic_auth = TRUE)

 

Best Answer
0 Votes
Thanks for working it out. I wasn't able to delve into it further since I'm an R beginner. I still think it would be a good idea for fitbit to accept the secret in the request body. All major server implementations do and it's easy for a client imlementation to think it works and move on without implementing the option to pass it in the header. (The MUST in the spec is for the server, not the clients).
Best Answer
0 Votes

Any news on this?

I am developing an integration for a huge Java system. My extension will be running in a liferay portal, and I am not allowed to open a server socket.

 

Integrating Google Fit is fairly straightforward because of the OOB flow. But integrating fitbit would require a separate web application that makes the user copy the code received by callback, or some other stupid workaround.

 

Adding this feature can't be that much work, since the back-end would be exactly the same; The code would only need to be displayed to the user rather than sent to the callback, or am I missing something?

Best Answer
0 Votes

@bennett-ITH: This is still a planned feature, but I do not have a timeframe to share, as it has not been prioritized.

Best Answer
0 Votes