When using IFTTT, there’s an option to call an IFTTT action via a webhook, which I talked about a little while back. However, there’s no way to ensure you are calling the IFTTT action. With most IFTTT actions, you can trust that you are the one triggering the action as the actions are based on a trusted action, just as a new record in a blog’s RSS feed or a new post to your Twitter account. However, with a webhook, anyone with the URL can call the webhook and trigger the action. And if the action is something privileged, like posting to the company’s Facebook account, for example, you want to ensure that only a known application is triggering the webhook.
If you have an IFTTT Pro+ account, this is actually pretty easy to do. One of the benefits of having an IFTTT Pro+ account is that you can have an IFTTT action do more than one thing. In my case, after the web request is triggered (when I call the IFTTT action), it will call another action to an Azure Automation Flow, which then logs into Azure Keyvault and verifies the API key that the IFTTT action receives. It does this by passing the value it receives to the Flow’s webhook. The low is then the verification of the ApiKey. Suppose the key matches, then the automation flow exits successfully. Suppose the key isn’t correct; the flow returns an HTTP error code of 500 and terminates. The IFTTT action sees the error is returned, and it stops the webhook from executing so that the post isn’t even posted to Facebook.
This is a pretty straightforward change to the IFTTT action, but it ensures that the action is only being executed by the application that is supposed to call it. And because the ApiKey being passed around isn’t hard coded anywhere (the application that calls the IFTTT action is getting the key from the same Azure Key Vault), if the key is changed in the Key Vault, it’s changed everywhere automatically.
Denny
