Recently I did re-evaluate the current possibilities when tasked with fully automated ARM template deployments of Logic Apps which contain API Connections. TL;DR; as of today there is still no sophisticated method for automating the authorization process of OAuth secured API connections. Microsoft still recommends the same custom PowerShell approach as back in 2018 when I first did evaluate this deployment aspect. Of course this should be understood as a general inspiration, rather than the ultimate solution. But in the year 2020 I would expect that there are already more sophisticated approaches, which ideally should have been integrated to Azure DevOps release pipelines, similar as the Azure Key Vault release tasks or the neat parameter mapping features of the Azure Resource Group Deployment task.
You might ask, why this is of relevance in the days of Service Principal access methods (aka App Users, AAD App Registrations asf.), Azure managed resource odentities or even simpler static API keys. Short answer: not all API Connections do support these advanced authentication mechanisms yet.
How to authorize OAuth connections (as of today)
In essence I see three choices:
- implement some semi-automated OAuth login process using f.e. PowerShell which needs manual intervention for doing the actual “login” (example) → moderate initial effort; can be re-used
- implement automated login process which f.e. follows the common OAuth 2.0 authentication flow. Login credentials could for example be stored and retrieved from Azure Key Vault in order to avoid security leakage → rather complex and relatively high initial invest, but can be re-used
- just open the affected API Connection ressources after they have been deployed and manually authorize them → low effort
Keep in mind, that #1 and #2 also need to be integrated to the automated deployment process with, for example, Azure DevOps releases. For #1 this will impose additional complexity, since the OAuth login dialog must somehow be invoked on the user’s client machine in order for him to take action. And strictly speaking, #1 and #2 do contradict the philosophy of truely automated releases (CI/CD) since they involve manual intervention.
My comment
In the end, one needs to weigh out the costs/savings of following a strict philosophy (automation; CI/CD) vs. following a rather pragmatic approach, where both sides have the same goals: streamlining the whole release process and making it as efficient as possible. For me, following choice #2 would represent that most elegant solution, which will only amortize in the mid-/longterm and is best suited for very mature customer/project contexts, where this very specific optimization would imho pay off the most. While choice #3 is the most pragmatic and also cheapest (in many ways) way to accomplish the same goal.