Query regrading Oauth Access Token and redaction of sensitive data

[Gopi_Bhattacharya]

Scenario:

We have created an Integration that uses User Defined (OAuth) credential type (How to use the User Defined (OAuth) credential type - Genesys Cloud Resource Center). Here we specify the loginUrl and the client credentials. Now in our scenario, we have different endpoints for the loginUrl for prod and non-prod instance. Is there a way by which this loginUrl can be made dynamic ? Else we will have to create 2 different integrations one for non-prod another for prod.

Also, we would like to understand the following for User Defined (OAuth) credential type :

1. The access token generated once, is it reused in subsequent API calls even though the API calls belong to different call/interaction sessions ? i.e. is this cached till the current token expires ?
2. The crednetials (url, clientid and secret and the accesstoken generated are redacted in the test window, does the sane hold good for the logs that get captured on Genesys cloud end when the architect flow executes ? Or the clietn id/secret gets printed in the logs when the data action is invoked?

Alternative approach :

For the scenario mentioned above, another approach could be to create two separate data actions, one for generating access token and other for the actual api call that will use the token generated. Next in the architect flow, first invoke the data action to generate the token, extract the token from the response, then invoke the second data action and supply the token generated as bearer auth header. Using this approach we can supply the loginUrl as a parameter to the first data action and we need not create 2 sets of data action every time. Below are my questions related to this alternative approach

1. Is there a way to still redact hide/redact the data consumed and response generated in the first data action invocation (for access token) in the logs ?
2. Can the access token generated using the alternative approach still be cached ? If no, is there a way to implement this caching easily within Genesys cloud ?

Kindly suggest the best approach.

Regards,
Gopi

[Jason_Mathison]

Is there a way by which this loginUrl can be made dynamic ?

An idea exists for this that you can vote for and add comments:
https://genesyscloud.ideas.aha.io/ideas/OPCFDA-I-21

You could pass part or all of the endpoint URI into the data action to connect to different endpoints. However, your authentication tokens would have to be regenerated anytime the cached token was for the wrong instance. That would probably be fine if you were only occasionally hitting the non-prod instance, but it would add some latency if you are constantly switching back and forth.

1. The access token generated once, is it reused in subsequent API calls even though the API calls belong to different call/interaction sessions ? i.e.

As these are "computer to computer" requests, data actions have no expectation that there would be any type of "user session" context to manage.

is this cached till the current token expires ?

Do data actions request a new Authentication token for every request? -...

1. The crednetials (url, clientid and secret and the accesstoken generated are redacted in the test window, does the sane hold good for the logs that get captured on Genesys cloud end when the architect flow executes ? Or the clietn id/secret gets printed in the logs when the data action is invoked?

We take protecting customer data VERY seriously. Your credentials are not logged out.

For the scenario mentioned above, another approach could be to create two separate data actions, one for generating access token and other for the actual api call that will use the token generated. Next in the architect flow, first invoke the data action to generate the token, extract the token from the response, then invoke the second data action and supply the token generated as bearer auth header. Using this approach we can supply the loginUrl as a parameter to the first data action and we need not create 2 sets of data action every time. Below are my questions related to this alternative approach

That seems like it would work. A couple of notes, there are several approaches that would cut down on the pain of managing two integrations. The first is that once you have your action working in non-prod, you could export the action and then import it into the prod integration. If the URL is part of the credentials then you wouldn't need to change the configuration of the action after importing it. A more automated approach would be to use "CX as Code" (Terraform) to manage getting the new action into your production environment.

1. Is there a way to still redact hide/redact the data consumed and response generated in the first data action invocation (for access token) in the logs ?

This data would not go into our logs. If you enable the flow execution history feature then those variables may be saved depending on how you configure it, however that data is not logged or exposed to Genesys employees.

1. Can the access token generated using the alternative approach still be cached ? If no, is there a way to implement this caching easily within Genesys cloud ?

Tokens generated this way would not be natively cached. I was going to suggest using a Data Table, however the documentation indicates that is not appropriate:

Genesys Cloud Developer Center

For your authentication data action you could use an AWS Lambda or Genesys Functions integration and have your lambda code cache the auth token(s) it retrieves. So after the first time it authenticates it passes those tokens back until they hit their expiration time.
Honestly though, unless generating a token is slow, has limits, or somehow expensive, I would go with one of the other approaches.

--Jason