Invalid verification code format

[goldenlink]

Hi, I'm trying to register login with my React frontend. On the front end, I use the react-faceboo-login component. On the response, I get the response. I add to the callback url
?code='signedRequest' and pass the response as the POST body.

On the Rails side, I get the following error.

Authentication failure! invalid_credentials: OAuth2::Error, {"message"=>"Invalid verification code format.", "type"=>"OAuthException", "code"=>100, "fbtrace_id"=>"A74qVKtjjtF"}:
{"error":{"message":"Invalid verification code format.","type":"OAuthException","code":100,"fbtrace_id":"A74qVKtjjtF"}}

I've been checking my redirect urls, and so on. But seems not the issue here. I've specified FB v3.0. I tried with 2.12 and 3.3 but I get the same issue.

I'm not sure how to debug further.

Thanks for your ideas .

[yuvi17]

Linked to #204
@goldenlink can you have a look at this and see if this solves your problem.
Also, this SO link might also be helpful https://stackoverflow.com/questions/16176208/rails-could-not-authenticate-you-from-facebook-because-invalid-credentials

[goldenlink]

Thanks, actually found out partly the issue here. On the front-end, it uses directly the Facebook SDK to handle profile retrieval. It actually does not return the code to be passed to the callback, but it returns the profile hash with an access token.

Facebook documentation claims that I should actually check the access token rather then exchange it.
https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow#checktoken

I think the library needs a patch in such case to handle the token checking with the user hash as an alternative method to identify against Facebook.

My idea would be to POST the callback with the returned hash from facebook to the callback. In the callback_phase, identify the format of the data and check the token.

GET graph.facebook.com/debug_token?
input_token={token-to-inspect}
&access_token={app-token-or-admin-token}

Anyone has an insight on this ? or an alternate approach ?
BR

[yuvi17]

@goldenlink are you getting the same error, invalid hash. The issue AFAIK was that the FB API was returning data in different formats for different versions, for a patch was merged. Can you check if you are using the correct versioned API and the format is set in accordance with what API will return?

However, if what you have described is the case, I think more investigation is needed.
cc : @simi Shall we be putting this as something that needs a patch?

[simi]

Isn't this related to #315 ❓

[yuvi17]

@simi yes, this looks related to that. How are you planning to proceed on that?

[goldenlink]

@yuvi17 Well, I'm using v3.0 now. But the issue is the same whatever is the API. Actually, this is the FB JS SDK that causes the issue. Even if you ask for a code and not a token, it decides based on the platform, ... to return directly the profile hash and access_token.

This is actually the full authentication data. But this data has to be validated by the server on sign_in / register to guarantee authenticity of the data sent. One could easily claim an other email while sending back the FB data changed.

In my case, I was using the FB SDK through the react-facebook-login component which integrates FB SDK in JS. Sounded reasonnable.

I'm going to patch something, but I'm not very fluent in the devise stuff. So I'm pretty unsure of my path on this.

[goldenlink]

So, after a little pause to get some fresh eyes, here what I found. Facebook is actually sending the code, but hidden in the signedRequest response.
signedRequest is a JWT token. In the payload part, we find 'user_id', 'algorithm', 'issued_at' and the 'code'.
So omniauth-facebook code could be updated to accept directly the signed request as a different named param, or let the user handle decoding and extracting his "code". I've got no idea which is the best strategy.
I'd prefer anyway not to drag with me in the project a custom gem with no reason.

[simi]

Thanks for your info Can you provide some example please? Dne pá 5. 7. 2019 12:01 uživatel goldenlink <notifications@github.com> napsal:

…

So, after a little pause to get some fresh eyes, here what I found. Facebook is actually sending the code, but hidden in the signedRequest response. signedRequest is a JWT token. In the payload part, we find 'user_id', 'algorithm', 'issued_at' and the 'code'. So omniauth-facebook code could be updated to accept directly the signed request as a different named param, or let the user handle decoding and extracting his "code". I've got no idea which is the best strategy. I'd prefer anyway not to drag with me in the project a custom gem with no reason. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#321>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABPLEEJ3ZF3WMLEMDSGKELP54LXBANCNFSM4H3TG5BQ> .

[goldenlink]

Well, actually, digging and digging is a good thing. The case was correctly handled by using cookies. The only issue was about facebook not setting my cookie and the cookie not being transmitted in my REST XHR. I've sent a PR #323 to accept signedRequest over parameters not only cookies.

Let me know what you think. At least it solved my mysteries and let me learn a lot about facebook SDK and omniauth :)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.