You can store these changing variables in a configuration table (You will have to have an entity for this table). Use these changing values as workflow parameters. Load the data at the beginning of workflow from that entity using a projection delegate. This way, for each environment, the configuration table will have environment specific data and workflow will work without any issues.
This is just a suggestion and any other suggestions are welcome!

From 24R2 release, along with oAuth capability in IFS REST Task, it comes the possibility to externalize URLs. You can parameterize the URL and set a value to the parameter in a different page outside of the Workflow designer, known as ‘IFS REST Task Configurations’. You can set this parameter to ‘cfg.abc.com’ in CFG env and ‘uat.abc.com’ in UAT env. And this table won’t clone even when the environment is cloned. So the URLs you provide won’t replace in cloning process.

Thanks ​@Lahirumala de Mel ,

How about the user and password for basic authorization?
Are these supported as well?

Hi ​@Buddhi Gunasekara ,

I would NOT do this as a configuration. Reason being , I do not want to expose user, password, or client secret from client OR database.
If we need to follow that approach then all those attributes should be obfuscated and then it will become a MOD. 
I think a better approach is to follow the process described by ​@Lahirumala de Mel  using 24R2.

If you are using headers to set username and password, they can be externalized as well using the ‘Free Text’ type IFS REST Task Configurations.

​@Lahirumala de Mel ,

Many thanks. Will try when we get 24R2.