Open API: Auth0 Client Credentials Option Missing + Secret Configuration Variable Not Working

[matei]

Goal
Authenticate with custom backend API using Auth0 client credentials flow (machine to machine).

Hey there!

Does the OpenAPI resource support Auth0 client credentials flow? It seems like the options for normal REST resources were updated to include Auth0 (instead of the generic OAuth 2.0), but the same is not available for OpenAPI.

Is there some limitation for OpenAPI, or were the options just not updated?

@kbn

Auth0 authentication method is missing documentation

Fyi, circling back to confirm that the update to make this clearer in the product was completed about a month ago! Thanks to @JQ105 's question and feedback here, we've changed the wording in the Authentication dropdown from the too-generic Auth0 to Auth0 Client Credentials with a notice that points to the relevant docs, and even suggests using the OAuth 2.0 option instead for use cases outside of the client credential flow. So when you are configuring a resource and select this Authentication …

[matei]

Update
I was able to verify that the OpenAPI resource authenticates perfectly fine when using the Bearer token method directly. However, the Client Credentials flow with the generic OAuth 2.0 still does not work -- Retool does not seem to be retrieving the access token at all.

The dedicated Client Credentials flow option in a REST resource with the exact same auth setup works perfectly fine.

[matei]

Well... after some dark magic, it works.

Quite honestly, I'm not sure why it works now. All of the configuration variables and resource setup are exactly the same as before.

Only thing I changed was my own Auth0 config, which initially did not authorize my Auth0 app with any Auth0 API—seemingly a requirement for returning an access token from the /oauth/token endpoint. Amateur problems.

This allowed me to verify my Auth0 access token endpoint and authenticate with my API locally.

Unfortunately, the Auth0 config change didn’t solve my problem: Retool wasn’t successfully returning a token from the endpoint I just verified locally—at least not when using a secret config variable for the Client Secret field.

But eventually, after:

1. Following the "Debugging Sent/Token Values" instructions here
   

   

2. Using Requestbin as the Access Token URL (since Retool Workflows doesn't seem to expose the auth headers) to inspect the auth headers (specifically client secret) sent from the Retool OpenAPI resource configuration
   

   

3. Using a Retool workflow as the server url in my OpenAPI spec (i.e. I added a public Retool workflow endpoint as the "server url" in the spec)
   

   
   
   ...to inspect the Bearer Token
   
   

I was eventually able to confirm that both the Client Secret (in a secret Retool Configuration variable) and the Bearer Token were being correctly passed.

That confused me, since nothing really changed but the endpoints. So I went back to the resource, changed the endpoints back to the real ones, hit save 10+ times, reloaded my test app, and authentication went through

TLDR;
Not sure if this was just me missing something simple or if "jiggling" the problem just made it work? But if anyone else comes across this issue, I hope this helps!

---

Below was my draft post of things I was trying before everything just worked, if helpful for Retool team or to spare anyone else from trying the same

Another Update

I was able to isolate the problem down to using secret Configuration Variables in the OpenAPI resource:

• Pasting the client secret as plaintext into the Client Secret field on the OpenAPI resource works fine! But, that's bad bad :
• Creating a not-secret configuration variable for the Client Secret also works fine! But... also not good
• I tried encoding the client secret as base64 (both url-friendly and not) before adding it to a secret Config variable. No luck
• I tried wrapping the secret config variable in a template string. No luck
  {{ `${environment.variables.AUTH0_CLIENT_SECRET_MAGIC_APPLY_BACKEND_API}` }}
• I tried trimming the whitespace. Nada. {{ environment.variables.AUTH0_CLIENT_SECRET_MAGIC_APPLY_BACKEND_API.trim }}

Again, the REST API resource does not have this issue. Using secret config variables does not cause any issues in the REST resource.

So given the above, I would disqualify the limitations on secret config variables listed here as the issue:

And I'm left thinking...