Connecting to a 3rd party API only using a grant_type=refresh_token

[msaucier]

I'm trying to integrate a 3rd party API using OAuth2 with a grant_type=refresh_token.

The authentication call format is the following:

login.example.com/oauth2/token?grant_type=refresh_token&refresh_token=

The response contains a bearer access_token, a refresh_token and the api_server URL for subsequent authorization refresh calls.

{
“access_token”: “XXXX” ,
"token_type": "Bearer" ,
"expires_in": 1800,
"refresh_token": "YYYY",
"api_server": "https://05_api_server@example.com"
}
I cannot find a way to configure the REST API Resource to use this authentication model, any help would be appreciated.

[Shawn_Optipath]

Hi @msaucier,

What have you tried so far? Can you please share a few screenshots? Below is a typical OAUTH2 setup (for Gmail) as an example.

[msaucier]

I've tried a lot of options, even tried the custom Auth path. The issue is I don't have a client id and secret, the only thing I have is an initial token and the /oauth2/token endpoint, from there I need to first call the http://login.example.com/oauth2/token?grant_type=refresh_token&refresh_token=<initial_token> endpoint to get the auth response below:

{
“access_token”: “XXXX” ,
"token_type": "Bearer" ,
"expires_in": 1800,
"refresh_token": "YYYY",
"api_server": "https://05_api_server@example.com"
}

Then I need to use this response api_server endpoint and access_token to make API calls. Once the Bearer token expires I need to use the refresh_token and make an auth call to the same /oauth endpoint above using the refresh_token this time to start the auth loop and API calls again.

[Shawn_Optipath]

I've done this before creating a custom app in make.com. It "should" be possible here though I haven't tried it in Retool before. Are you ok to share your 3rd party and its documentation?

[MiguelOrtiz]

Hey @msaucier

I think custom Auth path is the way to go. The steps in the auth should look something like:

1. Make the call to your first endpoint
   

   

2. Define variables based on the response
   

   

3. Use the variables for your token, and refresh auth workflow (where you can redefine the token variable)
   

   

The only thing I'm not sure it works is whether you can use the variables within the "Base Url" field, as i think is expecting a hard coded base Url

[msaucier]

That's exactly what I tried at first with the custom Auth path, defining variables and storing the response values in them for later use. The issue I got with this is what you've highlighted, I cannot use the variable as the endpoint URL, I get a Retool error: "Only absolute URLs are supported".

I might have to go with a custom Node.js/Express solution for this.

[Jack_T]

Hi @msaucier,

Let me double check if there is any work around to the Retool error: "Only absolute URLs are supported".

If there is not one, I can make a bug report/feature request to address this for use cases such as yours.

I was hoping that @MiguelOrtiz's solution was the best way to set up multi-stage auth but I understand that the input field is asking for a base URL which does not fit the situation

[Darren]

Hey all - I recently ran into a use case that similarly required being able to dynamically set the base URL of the resource, so we've already had some conversations internally around allowing such functionality. There isn't an implementation timeline just yet, but we'll let you know when that changes.

To @msaucier - it looks like you're on an Enterprise plan, which opens up the alternative to dynamically update the resource configuration via the API from within your custom authentication flow. Let me know if you have any questions about that implementation.

[Michael_Huang]

@msaucier I might not fully understand your use case but note that Base URL does not need to be set.

In Custom Auth, define a variable with your URL

Reference your variable when making a request

Please let me know if I'm missing something or could otherwise assist in your use case.

[Darren]

Ah that's a good callout, @Michael_Huang - I wasn't thinking about the ability to reference the defined variable from outside the resource configuration itself. Based on my understanding of @msaucier's use case, that should definitely be sufficient.