Some might Google the word Authorizing or Authorization but I write it with the letter S. Now it’ll come up in your search results with a Z I’ll get to it.
There are a few ways you can lock down an HTTP triggered Logic App or Flow so an unauthorised person can’t trigger your app. Microsoft provide some great documentation on this here including how to incorporate OAuth authentication into the Request trigger and restricting inbound IP addresses.
However, you might have a less sensitive application and want a much simpler solution than implementing OAuth authentication, so here’s one.
By default, a Logic App (or indeed a flow) HTTP trigger is protected by a Shared Access Signature. The encrypted signature is included as a URL query. This is great to stop your average member of the public from guessing your URL, but it’s not that great if someone gets their hands on the trigger URL for your app.
The following is probably not hack-proof for someone with the means and the motivation, but it’ll stop the (unlikely) event of someone finding out the URL for your trigger and running it.
An example of this might be if you have a web hook on an event in your CRM system or another SaaS product, and any administrator of the system can see the web hooks and the URLs you’ve set up.
You don’t want someone copying your web hook URL and using it elsewhere in a stroke of administrative misadventure.
I’m going to use a header for this.
In the Trigger Conditions, type an expression like the one above. With this is place the Logic App won’t trigger unless the HTTP request contains a header called Auth and the value is My-Secret-Key. Also tick Suppress workflow headers.
Let’s try it:
Now with the wrong header value:
This will still count as a trigger, even though the workflow doesn’t execute. As I understand it, you will still be billed US$0.000025 every time this happens, and it’ll subtract one from your massive ratelimit quota. The client still gets a 202 accepted response so they will know it’s a valid Logic Apps trigger but they’ll never know whether or not it’s done anything.
You could have just not included a response action in the app, in which case from the client’s point of view, they have no way of knowing what effect their actions are having.
It’s not foolproof, but it’s simple, and it gives you some peace of mind about the security of your logic app.
If you can’t use a header, you can either use the relative path in the trigger setup or a URL query in much the same way. I won’t go into details of these but the technique is pretty much the same. They’re no ideal though because in both cases the token will be exposed in the URL and visible to anyone with access to the place you’re using it.
William's IT Blog 