something smells with the OAuth2

[jesusdoesntsave]

hi there community...

i have a nagging problem when using the OAuth2 for authorization and then requesting the access tokens and stuff. i do get state and code back after the authorization. when doing the next step - getting the long access code - using this as an example from https://dev.fitbit.com/docs/oauth2/#access-token-request

POST https://api.fitbit.com/oauth2/token
Authorization: Basic Y2xpZW50X2lkOmNsaWVudCBzZWNyZXQ=
Content-Type: application/x-www-form-urlencoded

client_id=22942C&grant_type=authorization_code&redirect_uri=http%3A%2F%2Fexample.com%2Fcallback&code=123456789 

instead of the example reply there i get this: 

"errorType":"invalid_request","message":"Redirect_uri mismatch: http%3A%2F%2Fredeem.tpgrewards.com%2Fhealth%2F. Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."}],"success":false}"

how is this possible since i just used the same callback url to get the authorization and now just trying to get the access tocken so i can test some requests? the url in the token call matches the app setup for the client id which is the same as the one used when doing the oauth2 athorization.

what am i doing wrong?

thanks...

[JeremiahFitbit]

Can you share the request (with your Authorization header obfuscated) and your authorization page URL? I'm guessing there is a minor value mismatch.

[jesusdoesntsave]

hi Jeremiah...  thanks for the reply...

this here is what i'm posting to https://api.fitbit.com/oauth2/token

client_id=229YKV&grant_type=authorization_code&redirect_uri=http%253A%252F%252Fredeem.tpgrewards.com%252Fhealth%252F&code=bb2a1cde164176af17246c8da9bbcce6771477dc

the headers are:

$token = base64_encode(sprintf('%s:%s', $app_id, $all_secret));

$headers = ["Authorization: Basic ".$token, "Content-Type: application/x-www-form-urlencoded"];

not that i'm using the same callback url for the authorization call too..

thanks again...

[JeremiahFitbit]

And what is the authorization URL that you send users to?

[jesusdoesntsave]

https://www.fitbit.com/oauth2/authorize ?!

[JeremiahFitbit]

...but what parameters are you passing to the authorization page?

The redirect_uri passed to the authorization page must match the value sent in the access token request.

[jesusdoesntsave]

it is. in both cases it is: http://redeem.tpgrewards.com/health/

that's also in the app setup...

[jesusdoesntsave]

sorry... just wanted to add that that is the url where i get the state and code parameters after the authorazion is gone through...

thanks again for your help...

[jesusdoesntsave]

i just tried this again. with a new fitbit account (friend) and new code gotten back from authorization. same reault. at this point it's becoming rather annoying...

why is this not working?

thanks...

[jesusdoesntsave]

so...  no explanation? it's just not gonna work and that's it?

[JeremiahFitbit]

Hey @jesusdoesntsave,

The OAuth 2.0 process is working perfectly for thousands of other apps using the Fitbit Web API. You have a problem in your implementation. We're happy to help, but we're primarily here to support using the Fitbit Web API, not troubleshoot your implementation of an industry standard protocol.

Here's a working flow (with my client secret obfuscated):

1. Redirect the user to https://www.fitbit.com/oauth2/authorize?response_type=code&client_id=228YX6&scope=activity%20nutriti...
2. User grants consent and is redirected to https://example.com/fitbit_auth?code=acdd9bffd9852642b52e9ffd35bcc5cc862a2d11
3. My app makes an Access Token request that looks like:

   POST /oauth2/token HTTP/1.1
   Authorization: Basic MjI4WVg2OnB1dF9yZWFsX2NsaWVudF9zZWNyZXRfaGVyZQ==
   Content-Type: application/x-www-form-urlencoded
   Host: api.fitbit.com
   Connection: close
   Content-Length: 128
   
   grant_type=authorization_code&redirect_uri=https%3A%2F%2Fexample.com%2Ffitbit_auth&code=acdd9bffd9852642b52e9ffd35bcc5cc862a2d11

The server responds with {"access_token":"eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0NTQzNjA3MDMsInNjb3BlcyI6Indsb2Mgd3BybyB3bnV0IHdzbGUgd3NldCB3aHIgd3dlaSB3YWN0IHdzb2MiLCJzdWIiOiIyNkZXRkwiLCJhdWQiOiIyMjhZWDYiLCJpc3MiOiJGaXRiaXQiLCJ0eXAiOiJhY2Nlc3NfdG9rZW4iLCJpYXQiOjE0NTQzNTcxMDN9.obfuscatedobfuscatedobfuscatedobfuscated123","expires_in":3600,"refresh_token":"obfuscated-obfuscated-obfuscated-obfuscated-obfuscated-obfuscated","scope":"settings profile location social weight heartrate nutrition activity sleep","token_type":"Bearer","user_id":"26FWFL"}

You can then make API requests and refresh the access token when it expires.

[JeremiahFitbit]

(The forum truncates the links for display. You may need to right click, copy link location, and paste somewhere to see the full URL.)

[jesusdoesntsave]

thanks Jeremiah...

i saw the flow you are describing and in my implementation there is nothing different. also if you work for fitbit you can see that my calls are referring to the url entered in the "Callback URL" field for the app settings and they both match (see image at the bottom)...

here... my code for authorization i have:

$my_client_id_from_fitbit = '229YKV';
$my_client_secret_from_fitbit = 'verysecretstringhere';
$my_callback_url = 'http://redeem.tpgrewards.com/health/';


and at the time requesting the access token:

$my_client_id_from_fitbit = '229YKV';
$my_client_secret_from_fitbit = 'verysecretstringhere';
$my_callback_url = 'http://redeem.tpgrewards.com/health/';

$token = base64_encode(sprintf('%s:%s', $my_client_id_from_fitbit, $my_client_secret_from_fitbit));
$http_headers = array ("Authorization: Basic ".$token, "Content-Type: application/x-www-form-urlencoded");

$call_url = 'https://api.fitbit.com/oauth2/token';
$code = 'code_i_just_got_from_authoriaztion_call';

$data = [
'client_id' => $my_client_id_from_fitbit,
'grant_type' => 'authorization_code',
'redirect_uri' => urlencode($my_callback_url),
'code' => $code
];

$data = http_build_query($data);

etc...

as you can see all 3 different occasions point to the same url. and the authorization works. so... you might understand that from where i am sitting the error for mismatched_url looks (and feels) - in the best case scenario - suspicious....

so, basically, my next step is to create a fresh new app and start form scratch... i'll recreate every steep so far and will report back.

thanks again for your reply...

Moderator edit: Be nice.

[JeremiahFitbit]

Can you capture your HTTP requests using a tool like Runscope Traffic Inspector?

We can't effectively debug your code, but problems are usually pretty obvious when looking at the actual HTTP request and response.

[jesusdoesntsave]

ok. i'll give it a try.  will report back...  thanks...

[JeremiahFitbit]

Just as a test, I did:

https://www.fitbit.com/oauth2/authorize?response_type=code&client_id=229YKV&redirect_uri=http%3A%2F%2Fredeem.tpgrewards.com%2Fhealth%2F&scope=profile

On consent, I was redirected to

http://redeem.tpgrewards.com/health/?code=f28319901d6ecbf0e78ea2ebb503c567ca3e8ecf

Then I did (client secret obfuscated):

POST /oauth2/token HTTP/1.1
Authorization: Basic MjI5WUtWOm9iZnVzY2F0ZWQ=
Content-Type: application/x-www-form-urlencoded
Host: api.fitbit.com
Connection: close
Content-Length: 135

grant_type=authorization_code&redirect_uri=http%3A%2F%2Fredeem.tpgrewards.com%2Fhealth%2F&code=f28319901d6ecbf0e78ea2ebb503c567ca3e8ecf

And that gave me a valid access token response.

[jesusdoesntsave]

ok. i have a question then...  based on your example the callback url was passed this code back:

f28319901d6ecbf0e78ea2ebb503c567ca3e8ecf

and then you made the  access token request using this code:

599935d42981eb29b3e74713ca839deb7c8f1032

if those are different how did yo uget the token?! aren't those supposed to be tha same?

thanks...

[JeremiahFitbit]

That was a copy/paste mistake, as I ran the test a few times. I have updated my reply. Yes, the two values should be the same.

[jesusdoesntsave]

that's exactly what i'm doing. except on authorization i get 2 paramters passed - the code and another one called "state". that's probably irrelevan to this discussion but never the less i though i'd mention it...

ok. well...  i'll use the proxy trace and will report back...

thanks again...

[JeremiahFitbit]

If you pass 'state' to the Authorization page, you will need to pass the exact same value to the Access Token Request.