Oauth 2.0 client credentials flow appears to be broken, cannot be inspected or tested

I'm attempting to wire up a REST API resource to use in my workflows, the service uses what I believe to be a fairly standard implementation of the Oauth2.0 client credentials flow. I've successfully authenticated with the service using Postman requests, and I've replicated it in retool using custom code, but I'm not able to get it working with Retool's provided implementation of the Oauth2.0 client credentials flow.
I've found several threads in this forum referencing the client credentials flow, none of which seem to have resolutions in which the flow actually works, the only solutions seem to be using a different auth flow, or implementing the client credentials flow yourself under the Cusom Auth system, so I'm not entirely sure retool's implementation of the client credentials flow is working for anyone (though, obviously it could be - people for whom it worked perfectly right away don't have a reason to post, I've just not seen any examples of someone having trouble with it finding a solution)

Here's a screenshot of how I've attempted to configure the resource:

Here is a screenshot of my attempt to use the resource failing due to an auth-related error:

And here's the auth flow implemented successfully using RestAPI blocks:

Note that the credentials and URLs are exactly the same in my working example as in the failing ones, I'm sending the same credentials to the same auth endpoint, and calling the same API route with the resulting token.

I've tried playing around with the options a bit to try and get the resource working, but nothing I try seems to make a difference, and I'm not able to inspect the actual auth request to see what might be going wrong. It could be something very simple, like maybe retool's implementation is trying to use JSON encoding for the request body to the token endpoint, which requires x-www-form-urlencoded (not sure if that's standard or not, though I've seen plenty of other services use this encoding type for the token request, and I think the oauth 2.0 protocol is meant to be encoding agnostic so there ought to be a config option), but without any visibility into the token request I really can't identify the problem or propose a solution.

Switching it a custom auth implementation or building out my own flow using RestAPI blocks like above isn't difficult, but I'd like to be able to delegate that complexity to retool's off-the-shelf solution if possible, and I get the impression I'm not the only person to lose time trying to get the client-credentials flow to work, only to give up and find a workaround.

At a bare minimum, we should really be able to TEST the oauth 2.0 token request from the resource config page, like we can with Custom Auth, currently the only way to see if your resource is working properly is to use it in a workflow, and there isn't a way to see the details of the token request from there, so I have no idea if the sanitized value in my request headers is an actual bearer token, or some malformed value.

Hi @Kai_Mollerud, here is what worked for one user using OAuth2:

On the other hand, custom auth is currently not supported in Workflows. I'll add your feedback to the internal FR.

I believe the tickets you're referencing are using the regular oauth2 flow, rather than the Client Credentials flow I'm using here. The client credentials flow is meant for non-user scoped authentication, and does not involve a callback URL, just a single api call which directly returns the access token.

Good callout! I was scanning the forum for topics related to Custom Auth in Workflows after the limitation came up during Office Hours. I apologize for the confusion.

We could try setting up the resource again to discard any entry errors on the Client ID/Secret. I ran into a different issue trying to reproduce yours, potentially related to the endpoint I'm making the request to. I'll reach out internally to see if there is something I'm missing because your current settings should work, specially after seeing how it succeeds when using blocks.

The issue I ran into is this one:

Using Custom API Authentication is the current workaround.

Could you send me a DM with the Access Token URL? Potentially, it's expecting extra value, header, or query params compared our standard flow. If the flow is the same, it could be bug on our end.

Having same issue. So glad to know that I am not alone. I set up a Basic Authentication Resource and then I set up a query in the Query Library calling the token endpoint. It returns an object with a data item containing the access_token. This at least validated my credentials and that am using them correctly In my case, the endpoint then expects the access_token to have a header prefix as 'Session' and then the access_token as an Authentication header. This all works fine in Postman with the client authentication sent as "Send as Basic Auth header", Grant type of "Password Credentials" and token name of "access_token". It also works fine as a Custom Authentication in retool (thank god), but in my case I am having to do a lot of transformations converting ids and passwords when one would just like to have it work OOTB. Incidentally, why is basic authentication not an option when creating a custom authentication workflow anyway? Presumably, the issue with Oauth 2.0 is the OAUTH2_TOKEN magic word is not being replaced in the method but - like others - it is hard to tell since I can't figure out a way to trace between the resource and the query. I'm not raising anything that has not already been raised above, but just checking to make sure I've not missed the solve on working with the OOTB approach. I am not a proficient programmer so I really appreciate the insights on this board.

Thank you for your feedback, @csorrow. It does look like a bug, we created an internal report for this issue. We'll update you here with any news.