I am trying to fetch credentials for my Rest API from AWS Secrets Manager. I can successfully retrieve the credentials, but our API requires the client_id and client_secret to be sent in the request body as URL-form-encoded (not encoded) as its an Oauth api. The API returns an authentication token in response, which we use as an OAuth token for other APIs.
Since secrets can only be used in the resource configuration, we attempted to include the client_id and client_secret in the body directly. We also tried adding them in the header as x-www-form-urlencoded. However, the API body is still being sent empty.
Our goal is to securely pass the client_id and client_secret from Secrets Manager to the auth API through the request body. Is there a recommended way to achieve this in Retool?
Any guidance on resolving this issue would be greatly appreciated!
I tried custom auth and we were able to successfully integrated the custom OAuth API in the auth workflow API option. However, we are facing an issue where the custom API does not retrieve values from the secret manager.
So now i am able to pass the client id client secret to the api but in the custom auth api we are not able to pass aws secrets, we are trying fetching values from secrets, but in the request, it is keeping the dynamically bound values without evaluating them.
The following configuration works for me, so I'm wondering what might be acting differently in your particular case. Can you try replicating this setup?
Even if this does work, I wonder if there's a particular reason we don't expose the secrets objects in custom auth flows. Those steps all run on the backend so it should still be secure. I'll reach out internally to see if this might be possible!
It doesn't specifically address your use case, but we recently pushed out an update that allows users to reference secrets from within a custom OAuth2 step. This is live on the cloud release and on stable version 3.114.
There is an additional fix coming down the line that will additionally enable secrets within an API Request step. We don't currently plan on enabling it elsewhere, in order to avoid exposing those values via the UI.
All that said, I don't think your use case necessarily requires a custom authentication flow. Let me know if my previous post is useful or if you're still running into challenges!
