In the last project I’ve been working on, I got a requirement from a client where he wanted to consume an API exposed from Logic Apps with the security of an API key only.
The Logic App HTTP Connector
This is easily achievable out-of-the-box in Logic Apps by using the access key appended in the URL of a Logic Apps that
The URL generated by this connector is the following:
https://prod-02.australiasoutheast.logic.azure.com:443/workflows/workflow-id/triggers/request/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Frequest%2Frun&sv=1.0&sig=access_key.
This access_key query parameter is the value that works as an API key to access this Logic App.
So, we can just expose this URL to our clients and they will be able to consume the Logic Apps with this layer of security. But the URL contains a lot of query string parameters that make the URL hard to read. It also contains a lot of unnecessary information that the client that is consuming the API does not need to know. And lastly, by reading the API, we don’t know what it will be returning to us as normal REST APIs does with URL like https://server/api/Entity (GET, POST, PUT, DELETE).
The Azure Function Proxy
So, the way we can improve the exposing of this URL to the client is by using some kind of API proxy and for that, I used the Azure Function Proxy.
To do that, I created some proxies in an Azure Function App with the following configuration:
As you can see above I have now a better Proxy URL (https://server/api/Customer) with a better naming convention using the api suffix and the name of the entity we are going to manipulate as good REST APIs. And all the parameters that I need
I’m expecting in the header of this request a key-pair with the name of
The catch here is that by receiving the access key in the header key-pair
Controlling keys and improving security
Once the access-key value is shared with the client, we can control when a new value of this key should be generated by going to the Access keys configuration in the Logic App and generating new values for Primary and Secondary keys as the picture below shows:
We can also improve even further the security of this Logic App, by just accepting requests from this particular Azure Function App, by getting its outbound IPs and adding to the list of IP ranges accepted to call the HTTP trigger:
Summary
In this post I showed a easy way to have api-key type of authentication using Azure Function Proxy with Logic Apps.
Please be aware that new changes and improvements are being made today for API Management that has better capabilities than Azure Functions Proxies and as soon they are released I’ll be posting about it here also.
See you around!!!