Forum Discussion
What service principal is used to authenticate Logic Apps to Azure resources?
This question is a bit more academic than practical, but I'm just trying to enhance my knowledge of how Azure authentication works under the hood.
The default way to authenticate managed Logic Apps connections is through an OAuth popup asking you to grant permissions. Based on my reading of the Azure docs, this means that you're granting access to the delegated permissions of a service principal. For connectors that access the Graph API, such a service principal in your tenant with the correct delegated permissions:
However, I'm struggling to find an equivalent service principal for connectors that use the Azure Resource Management API to interact with services like Log Analytics, sentinel, Logic Apps, etc. I do see a service principal called Azure Logic Apps, but it doesn't have any permissions associated with it. My understanding is that it would need to have the delegated permission user_impersonation to access Azure resources:
So my questions here are
- What Service Principal is used for the OAuth connection to the Azure Resource Management API?
- If the Azure Logic Apps service principal is used, how is it able to connect to the ARM API without any permissions? Is there some Azure magic happening under the hood here?
Hi jbfeldman,
Speaking to the question asked in your post's subject first, the best places to find the answer are either:
- Easiest approach: Under Logic apps blade in the Azure Portal;
- Moderate approach: Check the sign-in logs in the Azure Portal;
- Hardest approach: Under App registrations (not Enterprise applications) in the Entra ID blade in the Azure Portal..
Under logic apps
This is covered well-enough by the Microsoft documentation - which I'll link below, but one thing I wanted to point out is that you will have one identity per logic app. It's not a case of having a single servicePrincipal that automatically services all logic apps.
Technically, you can create a single user-managed servicePrincipal object and use it for all your Logic Apps, but this would be unusual and not wise to pursue as a default approach. User-managed identities are very useful in specific scenarios but they should be used only when needed, not by default.
Under sign-in logs
This is also adequately-covered by the Microsoft documentation, so I'll simply link it here:
Under app registrations
Within the Entra ID blade, choose App registrations and then All applications, as shown below.
Depending on how many registrations your organisation has and how good the naming convention is (or isn't), this approach can be like looking for a needle in a haystack.
Additional information
While every registered enterprise application will have an underlying servicePrincipal (which will surface in the App registrations section), the inverse is not true: servicePrincipals can be created as standalone (i.e. No matching enterprise app) to serve automation purposes.
Not seeing any Azure management API rights for the userPrincipal is not uncommon since the preferred approach is to use role-based access to define access rights. Role-based access can be inspected under the Roles and administrators menu item as shown below.
Cheers,
Lain
Hi Lain, this is not really correct. What you're describing is only true if you use managed identities to authenticate logic apps. While you can use managed identities in Logic apps (which as in the docs you linked, will create a Service Principal for each logic app) it is not required. My question is specifically about the scenarios where you do not use a managed identity for authentication, and instead use Oauth for authentication. Most Microsoft-built logic app connectors will let you choose between the two
For connectors using the Graph API, as I stated, I was able to find the Service Principal (which can be used by multiple logic apps) that was used to authenticate the connection. But I'm struggling to find a similar Service Principal for connectors that use the Azure Resource Management API
Hi jbfeldman,
I wouldn't mind knowing which part of what I outlined is incorrect.
I can't really add anything new for your first question around discovering which servicePrincipal is used for which app, while for you second, (covered under "additional information"), I can only reinforce that it's quite normal for permissions to not show on the screen you have in your original post since they're most commonly assigned via roles, not the individual API categories (Azure API rights are broken into many separate categories).
Expanding on Azure rights a little, if roles are what I see being used the most, then second on the list would be the direct assignment of rights to resources such as subscriptions and resource groups, which also doesn't surface on the API permissions screens.
Cheers,
Lain
Considering this:
- What Service Principal is used for the OAuth connection to the Azure Resource Management (ARM) API?
- When Logic Apps connect to Azure resources, they often use Managed Identities (either system-assigned or user-assigned) for authentication. Managed Identities are essentially service principals managed by Azure, and they allow Logic Apps to authenticate to Azure Resource Management APIs without needing explicit credentials.
- For connectors that require OAuth, the authentication process typically involves granting permissions to a service principal associated with the Logic App or the connector itself. This service principal acts on behalf of the Logic App to access the ARM API.
- How does the Azure Logic Apps service principal connect to the ARM API without explicit permissions?
- The Azure Logic Apps service principal itself doesn’t inherently have permissions. Instead, Azure uses role-based access control (RBAC) to grant the necessary permissions to the Managed Identity of the Logic App. For example, you might assign the Logic App's Managed Identity a role like "Contributor" or "Reader" on the target resource group or subscription.
- The "magic" here is that Azure handles the token issuance and validation process behind the scenes. When the Logic App makes a request to the ARM API, Azure validates the Managed Identity and ensures it has the appropriate RBAC permissions to perform the requested action.
Hi Kidd, I understand what you're saying, but in the scenario I described in my original post I am not using any managed identities.
For connectors that require OAuth, the authentication process typically involves granting permissions to a service principal associated with the Logic App or the connector itself. This service principal acts on behalf of the Logic App to access the ARM API.
This is correct, but I'm not able to find that service principal for connectors that utilize the Azure Resource Management API, only for connectors that utilize the Graph API
The "magic" here is that Azure handles the token issuance and validation process behind the scenes. When the Logic App makes a request to the ARM API, Azure validates the Managed Identity and ensures it has the appropriate RBAC permissions to perform the requested action.
This isn't the case in my question, because I'm not using Managed Identities
- What Service Principal is used for the OAuth connection to the Azure Resource Management (ARM) API?
