When using Azure Logic Apps in an integration setting, we often want to connect to legacy on-premise enterprise databases and APIs. To connect VNET based ‘standard’ Logic Apps (connectors) to on-premise services you would be able to use a VPN or Azure ExpressRoute and the out of the box connectors, but if you used the Logic Apps Consumption tier, that resides in the Multi-tenant Azure Logic Apps environment, you need to use Azure Data Gateway & Data Gateway connectors to provide inbound database and http connections via an outbound connection from an on-premise machine that has the Data Gateway software installed.
Why do we sometimes use the ‘consumption’ tier of Logic Apps? Because Azure serverless helps you spend less on managing your infrastructure, as you don’t have to spend much time and energy on discussing and addressing hosting, scaling, and monitoring solutions, enabling you to develop faster, code less, simplify, and scale flexibility.
To connect to an on-premise http endpoint from a consumption tier Azure logic app you would use the data gateway, create a ‘custom’ logic app connector and then use this connection through an ‘API connection’ in your Logic Apps flow. (https://docs.microsoft.com/en-us/connectors/custom-connectors/define-openapi-definition)
1. Problem
Azure Logic App custom connectors have no security options for connecting to an OAuth 2.0 protected endpoint. The only options seem to be: No authentication, Basic Authentication and Windows Authentication.
When you try to add the “Authentication” header in the swagger definition of the Logic Apps Custom Connector, the Azure portal throws an error saying you have to use API Key based authentication in the swagger definition and define the API key header name as “Authorization”.
But even when you do use ‘API Key’ based authentication in the swagger definition using the API Key header field “Authorization” (using the “securityDefinitions:” & “security:” sections of the swagger definition), this only works to pass static strings through the Authorization header, that can be changed at deployment time, not dynamic token strings as is required with OAuth 2.0 tokens.
2. Workaround
The OAuth access token is normally sent to the service in the HTTP Authorization header prefixed by the text ‘Bearer‘, but historically, some services allowed, and do still allow, the token to be sent in the post body parameter or even the query string.
If you are lucky enough to have an API endpoint that still accepts this, you can send the token through an http query parameter instead of through the “Authorization” http header. In this case you will have to (and be able to) add the http query parameter to your Logic Apps Custom Connector definition e.g. “access_token” and update your logic apps flow to generate the token from the auth endpoint (also via Logic Apps Custom Connector through a data gateway) and then send it through the query parameter without the ‘Bearer‘ prefix.
This then still allows you to connect to on-premise OAuth endpoints from consumption tier Azure Logic Apps through an Azure Data Gateway, further helping to reduce costs required when managing Azure VNET infrastructure for your logic apps.
