Use oauth_iparams with "agent" OAuth type

[gak_islonline (Gasper Kolar)]

Hi team,

I am seeking guidance on configuring OAuth for our remote desktop integration app.

Application Context:

We use OAuth for user authentication, necessitating the “Agent” OAuth type to allow individual logins to corresponding backend user accounts.

The problem is that we offer hosted or self-hosted solutions (backends), so our self-hosted users need to specify their server address via iparams during the OAuth process.

This is similar to what was discussed in Unable to use oauth iparams when using agent oauth type

Specifically, looking at this post Unable to use oauth iparams when using agent oauth type - #22 by Raviraj , it seems to hint that this was already resolved.

However after looking at the code and testing this I do not see how this was solved since oauth_iparams still seem to be unavailable when using “agent” oauth type.

Best regards,

Gasper

[zach_jones_noel (Jones Zachariah Noel N)]

Hey @gak_islonline,

Can you share your oauth_configs.json?

[gak_islonline (Gasper Kolar)]

Hey @zach_jones_noel,

Thank you for the quick reply. Sure thing. My oauth_config.json looks like:

{
	"client_id": "freshworks_dev",
	"client_secret": "********",
	"authorize_url": "https://server4.gak.islonline-dev.com/users/authz/oauth2/grant",
	"token_url": "https://server4.gak.islonline-dev.com/authz/oauth2/token",
	"options": {
		"scope": "read_session_id"
	},
	"token_type": "agent"
}

The token is used in callOAuth2App request defined like this in requests.json:

{
    "callOAuth2App": {
        "schema": {
            "method": "POST",
            "host": "server4.gak.islonline-dev.com",
            "path": "/webapi2",
            "query": {
                "he": "JSON1",
                "method": "<%= context.method %>",
                "hs": "<%= context.hs %>"
            },
            "headers": {
                "Authorization": "Bearer <%= access_token %>",
                "Content-Type": "application/json"
            }
        },
        "options": {
            "isOAuth": true
        }
    }
}

And finally I make the call from app.js like so:

client.request.invokeTemplate("callOAuth2App", { 
	context: {
		method: "integrator/oauth2/user/login/1",
		hs: sid
	},
	body: JSON.stringify({jwt: r.response})
}).then(async function (r) {
	console.log("OK", r);
}).catch((err) => {
	// TODO: How do I handle 401 on revoked token
	console.log("err", err);
});

This all works as expected. The OAuth2 “handshake” completes and the app is authorized on first open/use. I am also able to use the token to make requests.

I was just a bit surprised that I was not able to use oauth_iparams with the agent token type.

Best regards,
Gasper

[zach_jones_noel (Jones Zachariah Noel N)]

Hey @gak_islonline,
When using token_type: agent you would not be able to use oauth_iparams as this is something the admin would use while installing the app.

But you can use iparams.json to define the installation parameters.

[ThomasH]

Hey @gak_islonline,

I don’t know if I understood the issue at hand correctly.
You wrote:

… The problem is that we offer hosted or self-hosted solutions (backends), so our self-hosted users need to specify their server address via iparams during the OAuth process…

So is the server address different per installation or per user/agent within the same installation?

Tom

[gak_islonline (Gasper Kolar)]

Hi @ThomasH,

My apologies for the confusion.

So is the server address different per installation or per user/agent within the same installation?

The server address would be different per installation. So the Admin would configure the server address (along with client_id and client_secret or any other oauth_iparams) during the app install. But he would not authorize the app yet. Instead each user/agent would authorize the app using the oauth_iparams configured by the admin.

There might be a technical limitation to this which I am unaware of so I apologize if I am coming across as ignorant. I figured the config needs to be stored long-term anyhow since it’s required to negotiate token refreshing.

If you’ll allow it, I do have a follow up question (though I understand it might require a separate topic) after working on it for a while. How may I clear/reset/remove the users/agents token from app.js when it gets revoked by the user ? So if the user revokes the token and the OAuth requests start failing with 401 Unauthorized I expected the freshworks OAuth2 client to 1.) Try to refresh the token but when that fails (because tokens have been revoked) 2.) Discard the tokens. However from my testing the tokens are never discarded and user never gets the opportunity to reauthorize the app if he so chooses. May I clear/reset the users/agents token from the app.js?

Best regards,
Gasper

[ThomasH]

Hey @gak_islonline

thanks for clarifying - So what you need it pretty much what was added to the product during the discussion of the topic you already referred to.

Which makes me think that

• either it is not working for all usecases / not working properly
  or
• it is was not transferred to platform version 2.3 correctly

Until now you only shared the oauth_config.json with fixed values in your post above.
Could you please also share the version where you tried with oauth_iparams?

And where exactly did it not work?
As far as I remember agent level oauth the app as such renders with an “Authorize” button if not authorized (sorry if that is wrong, haven’t seen agent level for 1-2 years now).
Were you able to do the authorization?

Unfortunately I am not able to answer your second question.

Tom