KB: Understanding Microsoft-Owned APIs, SPs, and API Permissions

 

1. Microsoft-Owned APIs behave differently

  • The App Registration lives in Microsoft’s tenant (hidden from you)

  • You only see the Service Principal (SP) in your tenant

  • The Microsoft API SP never shows API permissions

  • This is expected and correct

Example:
Power Platform API → AppID 8578e004-a5c6-46e7-913e-12f58912df43 (Microsoft-owned)

2. API permissions are ALWAYS stored on the client application, not on the Microsoft API

When you grant a permission like:

CopilotStudio.Copilots.Invoke

It gets added to the client application's SP/App Registration, e.g.:

"My Application"
—not—
Power Platform API SP

So the client app will show:

✔ API permissions
✔ Delegated permissions
✔ Admin consent

The Microsoft API SP will show:

❌ Nothing
❌ No API permissions
❌ No scopes
❌ No roles

3. Why?

Because permissions are modeled as:

Client App → requests → permission → from → Resource API

The resource API (Microsoft-owned SP) does NOT keep track of who is calling it.

4. If you find a Microsoft API SP later and want to know “which app is using this API?”

You can reverse-search by the API’s AppID.

CLI:

az ad app list --query "[?requiredResourceAccess[?resourceAppId=='<API-ID>']]"

Graph:

az rest --method get \
  --url "https://graph.microsoft.com/v1.0/applications?$filter=requiredResourceAccess/any(x:x/resourceAppId eq '<API-ID>')"

This returns all client applications that added permissions for that API.

5. How to interpret what you see in the portal

When you open the client app (your app):

You see:

  • API permissions

  • Which Microsoft APIs it calls

  • Which scopes it needs

  • Who granted the consent

When you open the Microsoft API SP:

You see:

  • Nothing in API permissions

  • No scopes

  • No roles

  • Only basic properties

This is expected.

6. What actually happened in your case

You saw:

  • A Microsoft API SP: Power Platform API

  • A custom client app: "My Application"

  • API permissions were visible only on the client app

✔ Correct
✔ Expected
✔ This is how Entra ID models delegated permissions

7. The golden rule

API permissions always belong to the client app, never the Microsoft API.

To see who uses a Microsoft API → inspect the client apps, not the API SP.

To find those client apps → search by resourceAppId.

Comments

Post a Comment

Popular posts from this blog

KB: Azure ACA Container fails to start (no User Assigned or Delegated Managed Identity found for specified ClientId)

Image
When deploying secure workloads using Azure Container Apps (ACA) , teams often face confusion between User Assigned Managed Identities (UAMI) and App Registrations . While both entities are visible in Azure Active Directory and have similar identifiers (Application ID, Object ID), they serve very different purposes . This confusion can lead to authentication failures when accessing services like Azure App Configuration or Key Vault . A common issue occurs when a container app is configured with a managed identity, but the environment variables or role assignments mistakenly reference an App Registration instead, causing errors like: "No User Assigned or Delegated Managed Identity found for specified ClientId" This article breaks down the difference between UAMI and App Registrations, explains why this issue happens, and outlines the correct approach to resolve it. Symptoms Azure Container App fails to authenticate to Azure App Configuration or other services. Logs...
Read more

Electron Process Execution Failure with FSLogix

  Technical Note: Electron Process Execution Failure with FSLogix 1. Overview When running Electron-based applications in environments using FSLogix Profile or Office Containers , users may encounter issues where the Electron process fails to launch or execute properly . This behavior has been observed in Azure Virtual Desktop (AVD) , Windows Virtual Desktop (WVD) , and other environments where FSLogix filter drivers are active. 2. Symptoms Electron-based applications (e.g., desktop apps built on Electron, CLI wrappers) do not start , remain unresponsive, or terminate silently. No visible logs or error messages are generated by the application. Standard executables run correctly when placed outside of the FSLogix-controlled profile path (e.g., copying to C:\Temp allows execution). The issue is reproducible across all Electron apps in the FSLogix-managed profile. 3. Root Cause The issue is linked to FSLogix filter drivers ( frxdrv , frxdrvvt , frxccd ) interfe...
Read more

KB:RMM VS DEX (Remote Monitoring Management vs Digital Employee Experience)

Digital Employee Experience (DEX) and Remote Monitoring and Management (RMM) tools serve different purposes and cater to distinct aspects of IT and employee management. Digital Employee Experience (DEX) Focus: Enhancing the overall experience of employees with their digital workplace tools and environment. Key Features: User Experience Monitoring: Tracks how employees interact with software and hardware, identifying issues impacting productivity. Performance Analytics: Provides insights into the performance of applications from the end-user's perspective. Feedback Mechanisms: Allows employees to report issues and give feedback on their digital tools and environment. Employee Well-being: Monitors factors that affect employee satisfaction and well-being, such as system performance and usability. Proactive Support: Identifies potential issues before they become significant problems, enabling proactive IT support. Goals: Improve employee satisfaction and productivity. Ensure a sm...
Read more