Help porting over from Postman to Workato

[rharkness]

Using Postman, I have successfully retrived a bearer token and connected to the endpoints provided to me by the client.  
I am not having success taking this functioning logic and recreating it in Workato using the HTTP connector.
What I'm not sure about is whether or not my issue is that the client is using a username/password to authenticate the token endpoint and it appears in order to use a bearer token I must use one of the OATH HTTP options

Anyone have any luck retrieving a bearer token with just an username and password?
This may or may not matter, but the endpoints I'm connecting to require the token to be passed in the header

[rharkness]

My token appears to expire in 24hrs but I'm using Workato in an embedded environment which is not configured to allow me accerss to create or modify Project properties

[rajeshjanapati]

Hi @rharkness @gary1 

When dealing with sensitive information, we have another approach where the value is not stored in Properties, Lookup Tables, or anywhere else. Instead, it's generated dynamically within the flow whenever it expires.

Please refer to the image below — in place of the Python connector, you can use the HTTP connector. Pay close attention to the step comments for better understanding. Also, make sure to store the access token in a variable so it can be reused in the following steps of the recipe.

Hope this makes sense! If not, feel free to reach out for further discussion.

[mppowe]

You should totally make an idea for that, if one doesn't exist.  I'd vote for it in a heartbeat

[mppowe]

I'll add one thought to this thread, b/c I, too, have struggled with this problem in the past.  I've also had to put credentials in a POST body and not been thrilled about it.  But one extra thing you can add to fend off the API Police is to make a new Project meant to store secured assets.  For example, we have a Project called "Recruitment and Admissions", then I made one called "Recruitment and Admissions - Secured".  That's the project I stash recipes like this where I have to expose credentials, and then not everyone is given access to that project.  All the other stuff already mentioned still apply, as far as data masking and such, but at least this way there's some RBAC around the sensitive credentials among the developers.

And @gary1 , you're not a pastry chef, it says you're a Star Chef 😁

[shivakumara]

Hi @rharkness ,

Here's my recommendation for securely handling bearer token authentication using the HTTP connector in Workato:

Recommended Approach

1. Create an HTTP Connection with Username & Password Authentication

   Use Workato's HTTP connector to create a connection that securely stores and uses your username/password credentials.
   This avoids hardcoding or exposing credentials in recipes.
   This connection can then be reused across multiple actions/recipes.

2. Use the HTTP Connection in Your Recipes

   When using this connection in your recipe actions, the connector will handle the authentication step using the stored credentials.
   If your Bearer token has an expiration (e.g., 3600 seconds), you can build a logic check before any critical API call to ensure the token is valid.

3. Separate Token Generation from Business Logic
   It's a best practice to modularize your logic:

   Use a separate function or step early in the recipe to check token validity and regenerate if needed.
   Keep your token generation and API data actions decoupled for easier debugging, better reusability, and improved maintainability.
   
   Thanks and Regards,
   Shivakumara K A