Mismatch is redirect_uri throwing TokenError in OAuth Platform API

App Platform
, ,
1

Hello,

I am working on a new update for one of our marketplace apps and have encountered the following issue:

  1. fdk run (with or without tunneling via ngrok, does not matter).
  2. I open the custom configs page - http://localhost:10001/custom_configs (or an ngrok link e.g. https://e31718229926.ngrok.io/custom_configs ). All tested URLs are present in the 3rd party platform’s Valid OAuth Redirect URIs list.
  3. The OAuth redirect happens and I successfully authorize in the 3rd party platform.
  4. At the moment I am redirected back to the http://localhost:10001/custom_configs (or the ngrok url), I get the following error in the web browser (+ it is logged in the terminal with fdk):
TokenError
    at OAuth2Strategy.parseErrorResponse (C:\Users\Ilya\AppData\Roaming\nvm\v10.18.0\node_modules\fdk\node_modules\passport-oauth2\lib\strategy.js:358:12)
    at OAuth2Strategy._createOAuthError (C:\Users\Ilya\AppData\Roaming\nvm\v10.18.0\node_modules\fdk\node_modules\passport-oauth2\lib\strategy.js:405:16)
    at C:\Users\Ilya\AppData\Roaming\nvm\v10.18.0\node_modules\fdk\node_modules\passport-oauth2\lib\strategy.js:175:45
    at C:\Users\Ilya\AppData\Roaming\nvm\v10.18.0\node_modules\fdk\node_modules\oauth\lib\oauth2.js:191:18
    at passBackControl (C:\Users\Ilya\AppData\Roaming\nvm\v10.18.0\node_modules\fdk\node_modules\oauth\lib\oauth2.js:132:9)
    at IncomingMessage.<anonymous> (C:\Users\Ilya\AppData\Roaming\nvm\v10.18.0\node_modules\fdk\node_modules\oauth\lib\oauth2.js:157:7)
    at IncomingMessage.emit (events.js:203:15)
    at endReadableNT (_stream_readable.js:1143:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)

Unfortunately, starting the fdk in the debug mode does not provide any more logs/details of the issue. However, I’ve logged the exact response in the file C:\Users\Ilya\AppData\Roaming\nvm\v10.18.0\node_modules\fdk\node_modules\passport-oauth2\lib\strategy.js on line 358 and it is the following:

{ 
    error: { 
        message: 'Error validating verification code. Please make sure your redirect_uri is identical to the one you used in the OAuth dialog request',
        type: 'OAuthException',
        code: 100,
        error_subcode: 36008,
        fbtrace_id: 'Amd6GY4kmzoEhCIoAZe3aIz' 
    } 
}

How can I check what redirect_uri is sent in a request to the 3rd-party platform?

As for the OAuth config - it is working fine in the currently available version of the marketplace app. The only differences from the marketplace version in my local tested are the client_id and client_secret due to some 3rd party platform specific security settings, this is why a duplicate “test” version of the app has been created for development purposes in order to work with http://localhost:10001/custom_configs (see the “In development” switch in the top left corner of the screenshot).
I have been using the client_id and client_secret from it for local testing for a couple of years already.

image
image1082×862 49 KB

I’ve tried specifying different Redirect URLs, but this didn’t help. I’ve also checked this on a different machine and, unfortunately, the results are the same.

I’ve seen threads with similar issues here (thread #1, thread #2), but my case seems to be a bit different.

Can this be related to the recent platform security updates / OAuth template changes?
Could you please help with this?

1 Like
3

Hi IIlya,
If you are using product specific custom_configs page, there is a query parameter we add to the callback URL in the following way:
http://localhost:10001/custom_configs?product=freshdesk

Most probably you need to whitelist this product query parameter in the redirect_uri

2 Likes
4

Hello @prithvi,

Thank you for the reply!

All redirects to localhost are supported by default in such “test” unpublished apps - if you check the last screenshot from my message above it is “In development” mode (not “Live”) and there is a pop-up stating “http://localhost redirects are automatically allowed while in development mode only and do not need to be added here.” when I try to add any callback URLs containing the “localhost” keyword.
So, the http://localhost:10001/custom_configs?product=freshdesk should be supported by default.

I’ve created a ticket on dev-assist.freshworks.com as well, #31. There is a screenshot containing more details of the post_body file sent to the 3rd party platform. Here is the part of it:
grant_type=authorization_code&redirect_uri=http%3A%2F%2Flocalhost%3A10001%2Fauth%2Fcallback%3Fcallback%3Dhttp%3A%2F%2Flocalhost%3A10001%2Fcustom_configs%3Fproduct%3Dfreshdesk%26product%3Dfreshdesk&client_id=...

I can see that there are definitely two links there, the first one “http://localhost:10001/custom_configs” and the second one “http://localhost:10001/custom_configs?product=freshdesk” (the non-letter characters are encoded). This could probably be the reason of the issue.

Do you have any ideas how to fix / bypass this?

1 Like
5

Hm, the decoded redirect URL seems strange. It should just have a single product query param in the callback parameter. Let me check with the team on this.

3 Likes
6

Hey @ilya.belyavskiy

Sorry for taking so long to reply on this. So I looked into the code, and there seems to be a bug in the FDK. We will try to get a fix out ASAP.

2 Likes
7

Hello @prithvi,

Thank you very much for the update! Looking forward to the new fdk version.

8

Hi @ilya.belyavskiy,

I have initiated a private message with you on the forum inbox to gather a little bit more information on how this error occurs.

Appreciate your way of sharing the details about the problem you are facing :slight_smile: All the screenshots and info you shared so far were helpful to understand what isn’t working.

1 Like
9

Hello
There are some updates about this issue? I’m retrieving the exact same error in the same platform.

1 Like
10

@Matheus_Nunes - Not an update yet. Apologies for the delay.

Different OAuth providers (in this case, FB) work in different ways, so it causing a delay from our end research while applying fix should be quick.