What is the best way to store sensitive credentials using Retool? I currently have the sensitive credentials stored as state variables but was wondering if there was a better way to do so.
1 Like
@karimitani
Welcome to the forum!
What are the credentials being used for? Are they per user or per app?
Per app! Credentials for using the AWS SDK
You would have to create a resource and store the credentials there.... I think it depends on what you want to do but someone else just asked about this at the user level... so you could check
https://docs.retool.com/docs/custom-api-authentication#2-use-custom-auth-for-your-authentication-method
I took a look at the custom API authentication. The thing is, I'm just using a JS snippet with the AWS SDK programmatically to do what I need to do, and I want to use the variables in my snippet, but I want to make sure to keep them secret. Is there a way to do just that? (maybe custom environment variables?)
Hi @karimitani, environment variables currently aren't accessible in apps themselves, though making that a feature is something we're considering. At the moment, even if the variable isn't exposed in the app itself, it likely will still be exposed in the request that's sent from the browser so users could find it by inspecting the network tab, for instance.
1 Like
I think you would need to use some kind of custom encoding/decoding that exists at least partly outside of Retool
@Kabirdas thanks for your replies
I'm a coworker of @karimitani also trying to figure out a solution for this.
We made some progress and went with creating an API resource which uses AWS v4 authorization which is supported by retool. Instead of using the .js SDK to call cognito we can call the cognito admin REST api directly. This solves the issue of exposing our AWS creds in the browser.
This works well for us because the aws secret key is encrypted and stored on the retool backend (I think)
However we can't actually call the Cognito API because your aws v4 puts the authorization in the URL instead of headers. We need it in headers.
Using postman's similar aws sig4 features (postman lets you choose url or headers) we were able to make the API call we wanted
this is the API call we want to make (credentials are fudged)
curl --location --request POST 'https://cognito-idp.us-east-2.amazonaws.com/' \
--header 'content-type: application/x-amz-json-1.1' \
--header 'x-amz-target: AWSCognitoIdentityProviderService.AdminCreateUser' \
--header 'X-Amz-Content-Sha256: beaead3198fxxxxx0eba3' \
--header 'X-Amz-Date: 20220304T231239Z' \
--header 'Authorization: AWS4-HMAC-SHA256 Credential=xxx/us-east-2/cognito-idp/aws4_request, SignedHeaders=content-type;host;x-amz-content-sha256;x-amz-date;x-amz-target, Signature=xxxxx' \
--data-raw '{"UserPoolId":"us-east-2_xxxxx","Username":"danishnet_38@hotmail.com","DesiredDeliveryMediums":["EMAIL"],"TemporaryPassword":"Abc@12345","UserAttributes":[{"Name":"email","Value":"danishnet_38@hotmail.com"},{"Name":"email_verified","Value":"true"},{"Name":"custom:org","Value":"bob"},{"Name":"custom:yards","Value":"bob"}]}'
some possible next steps
- Perhaps you guys could add to your roadmap to support AWS sig4 in headers ?
- The only real reason we are using API resource is so that we can store our AWS creds somewhere secure. If we could just avoid putting the AWS creds in the browser and retrieve them securely we could formulate the request ourselves or use the cognito SDK.
- Maybe an API resource with custom authorization option is the way to go?
3 Likes
