Best way to secure HTTP call to child flow?

[BeckyBertram]

Although flows that are bundled in a solution can call each other natively, flows that have a SharePoint manual trigger are not allowed to be included in a Power Automate solution. That means I have to create my flow with the SharePoint trigger outside the solution, and then call the child flow (inside the solution) using an HTTP call. My question is: what's the best way to secure that call?

I've tried using the API Management service in Azure to wrap the URL, but I'm struggling because all the examples are for calling Logic Apps and are about 5 degrees away from what I'm trying to do, which is to simply add security to my HTTP call. Can anyone provide any guidance? (Am I missing something really simple?)

[efialttes · Accepted solution]

Hi!
IMHO one of the bests questions posted this month. The problem you describe happens also when implementing Open.URL actions in Adaptive Cards to call Flows (dirty trick, I know)

Some interesting approaches in the following links:
https://www.about365.nl/2018/11/13/securing-your-http-request-trigger-in-flow/

https://community.dynamics.com/365/b/theressomethingaboutdynamics365/posts/secure-the-receiving-flow...

http://ratsubsharewall.blogspot.com/2019/11/secure-http-request-to-msflow.html?m=1

Feel free to discuss pros and cons, or suggest any other approach
Thanx!

[Jcook]

Hello @BeckyBertram

Have you tried using Secure inputs / outputs?

To enable this simply go to the action you want to apply this to.
Click the 3 dots,
Click settings,
If the action supports secure inputs and outputs you will be able to enable to enable this here.

Since Flow is on Cloud tenant in azure. You should be safe.

[BeckyBertram]

Thanks. At first I was trying to use API management but then realized all I'm doing is obfuscating the call, but that doesn't really secure things from the receiving end. I didn't really want logic inside my flow having to check any values, because by then, I've used up one of my flow runs. I like the idea of passing in a token into the trigger, and then having a trigger condition. That way, if someone attempted some sort of denial of service attack, it's Microsoft's problem and not mine, since it wouldn't count toward my flow runs and my code wouldn't execute.

[BeckyBertram]

Does securing the inputs and outputs do anything more than hide those inputs and outputs from the UI? I'm not so worried about people internally having access to the right stuff, but more hackers getting a hold of the flow's HTTP trigger URL and firing it.