07-31-2024 05:04 AM
Hi Everyone,
I have to use a cloud platform API in Workato. To get the temporary token of the API I need to provide the username and password in a POST request body in XML format.
The problem is that in the HTTP Connection it is not possible to use the authentication information (username and password) in a request body. There is an option for Header Auth but not for Body Auth.
How to deal with such connection? The only possible way was to create a connection without auth and then place a Post request with the username and password in the body request of HTTP action to get the token. However It is not recommended to leave such information in plain sight of a recipe.
Did any one face something similar? or could this be a feature request to add the option of body auth variables in HTTP Connection?
Thanks!
Solved! Go to Solution.
07-31-2024 10:01 AM
I've run into this before, and the most secure solution I've found is to store the password as an environment property with "key" or "password" in the property name (this will obscure it), and then use that property in the HTTP action body. Finally, you can right click > mask the HTTP action which will obscure the input/output logs and the password won't be visible in the job history.
The downside of this approach is that troubleshooting the HTTP action is impossible unless you unmask it, but if it's only for authentication it hopefully won't require any adjustments once it's up and running.
08-01-2024 09:29 PM
One other option I'll toss out that a Workato resource recommended to us involves creating the recipe function to do this authentication in a separate project that is secured. For example, if you have an "HR" project, then this might be named "HR-Secured" and your security roles restrict access to this project to only the necessary individuals. You can still mask the HTTP step if you want, or you can rely on the security roles. Either way, it does allow a more granular way to secure access to this private key since environment properties, to my recollection, can't secure individual entries. Of course, naming it as @gary1 suggests means it'll be masked, but still someone could accidentally (or not) mess with it.
Just another log to the fire. Enjoy!
07-31-2024 10:01 AM
I've run into this before, and the most secure solution I've found is to store the password as an environment property with "key" or "password" in the property name (this will obscure it), and then use that property in the HTTP action body. Finally, you can right click > mask the HTTP action which will obscure the input/output logs and the password won't be visible in the job history.
The downside of this approach is that troubleshooting the HTTP action is impossible unless you unmask it, but if it's only for authentication it hopefully won't require any adjustments once it's up and running.
08-01-2024 09:29 PM
One other option I'll toss out that a Workato resource recommended to us involves creating the recipe function to do this authentication in a separate project that is secured. For example, if you have an "HR" project, then this might be named "HR-Secured" and your security roles restrict access to this project to only the necessary individuals. You can still mask the HTTP step if you want, or you can rely on the security roles. Either way, it does allow a more granular way to secure access to this private key since environment properties, to my recollection, can't secure individual entries. Of course, naming it as @gary1 suggests means it'll be masked, but still someone could accidentally (or not) mess with it.
Just another log to the fire. Enjoy!
08-02-2024 01:06 AM
Thank you for the idea! I believe this could be more secure than using the environment property.
I had another idea I want to test. It is to make the request outside Workato then use Workato API to write the temporary token in the environment or project property. This need to be done every couple hours but it will be more secure.
Will try the ideas and go with what works better until Workato implement body Auth in HTTP Connections.
Thank you both for the help @gary1 @mppowe !