A Developer's Guide to Microsoft Entra ID Application Identities

1. Introduction

You’re building an application. You need it to read a secret from Azure Key Vault or call the Microsoft Graph API. You go to the Azure portal to grant permissions and are faced with a choice that seems simple but has profound security implications: do you use a Service Principal or a Managed Identity?

They both seem to do the same thing—give your application an identity so it can access resources. So which one do you choose, and why does it matter so much?

Getting this choice right is the difference between managing a pocketful of risky, high-maintenance keys and embracing a modern, automated, "secret-less" future. This guide will demystify these concepts and give you a clear framework for making the right decision every time.

2. The Core Problem: The Burden of Secrets

For years, the standard way to let an application authenticate was to create a client secret or a certificate. These are, for all practical purposes, passwords for your application. You generate them, copy them, and paste them into a config file, an environment variable, or a secret vault.

This creates two massive problems:

• Secret Sprawl: These powerful credentials get scattered across different environments, CI/CD systems, and developer machines. Every location is a potential point of failure.
• Operational Overhead: These secrets expire. Someone is responsible for manually rotating them, which is a tedious and error-prone process that is often neglected, leaving long-lived, powerful credentials active for far too long.

This is the problem that Managed Identity was born to solve.

3. The Two Types of Application Identity

To understand the solution, let's use an analogy. Imagine you need a specialized job done in your secure corporate office building. You have two options for hiring help:

• The External Contractor (Service Principal): A third-party expert you hire. They are flexible and can work anywhere, but you are responsible for their security and access.
• The Built-in Maintenance Robot (Managed Identity): A trusted, automated part of the building's own infrastructure.

Service Principals: The Flexible External Contractor

A Service Principal is a general-purpose application identity. It's the "who" that represents your app when it needs to access resources.

• How it Authenticates: To let this contractor into your building, YOU are responsible for creating a key for them—a client secret or a certificate. You must securely deliver this key to the contractor (your application), and you are responsible for changing the locks (rotating the secret) periodically. The entire security burden of that credential rests on your shoulders.
• The Risk: If that key is lost, stolen, or accidentally posted on GitHub, an attacker can impersonate your contractor and get in.
• When to Use: You use a Service Principal when your application is running OUTSIDE of the Azure ecosystem. The contractor model works because they can take their key and use it from anywhere:
  • A GitHub Actions workflow deploying resources to Azure.
  • An application running in AWS or GCP that needs to call the Microsoft Graph API.
  • A script running on your local developer machine.
  • An application running on an on-premises server.

Level Up: The Modern Contractor (Workload Identity Federation)

The traditional contractor model is powerful, but it still has that one major weakness: the key (client secret) you give them. What if you could hire that same flexible, external expert, but instead of giving them a key, you create a diplomatic agreement that allows them to use their own trusted ID from their home country?

That’s exactly what Workload Identity Federation does. It’s a modern, secret-less authentication method for Service Principals. It uses what's called a Federated Credential.

• How it Authenticates (The Secret-less Part):

  1. Instead of creating a client secret, you configure a trust relationship on your application in Entra ID. You are essentially telling Azure: "I trust tokens that are issued by this specific external system (like GitHub Actions for a specific repository, or an AWS role)."
  2. The external workload (e.g., your GitHub workflow) gets a short-lived token from its native platform.
  3. It presents this trusted token to Entra ID.
  4. Entra ID verifies the trust and exchanges it for a standard Azure AD access token.
  5. The contractor now has temporary access, all without ever handling a secret created by you.

• The Key Takeaway: Workload Identity Federation is the most secure way to handle external workloads, combining the flexibility of a Service Principal with the secret-less security of a Managed Identity.

• When to Use It: Use it in the exact same scenarios as a traditional Service Principal, but whenever the external platform supports issuing OIDC tokens. It is now the best practice for:

  • GitHub Actions, GitLab CI, or Azure DevOps pipelines.
  • Applications running in AWS or GCP.
  • Workloads running in Kubernetes.

• How are Permissions Assigned? This is a critical point: the way you assign permissions does not change. The Service Principal object in Entra ID is still the identity that gets the access. You assign permissions to it in the same two ways:

  • For Azure Resources (Key Vault, Storage): You go to the resource's Access control (IAM) blade and assign an RBAC role to the Service Principal.
  • For APIs (Microsoft Graph): You go to the API permissions blade of the corresponding App Registration and grant API permissions.

The only thing that changes is how the application authenticates. The authorization model remains identical.

Managed Identities: The Trusted Built-in Robot

A Managed Identity is a special, Azure-native identity whose credentials are fully and automatically managed by the Azure platform itself.

• How it Authenticates: The robot is already a trusted part of the building. It doesn't need a key that you create. When it needs to access a secure room (like Azure Key Vault), it simply makes a request to the building's central security system (a local Azure endpoint). Azure verifies the robot's identity internally and hands it a temporary, short-lived access pass (an access token). You never see, touch, or manage a secret. This is secret-less authentication.
• The Benefit: This completely eliminates the risk of leaked credentials, as there are no credentials for you to manage or leak.
• When to Use: This is your default, preferred choice whenever your code is running INSIDE of Azure:
  • An Azure Function App reading a secret from Azure Key Vault.
  • A web app on Azure App Service accessing Azure SQL Database.
  • A script on an Azure VM reading files from Azure Blob Storage.

Quick Guide: System-Assigned vs. User-Assigned Managed Identities

Managed Identities come in two flavors:

• System-Assigned: The robot is bolted to one specific machine. Its identity is tied 1-to-1 with an Azure resource. If you delete the VM, the identity is deleted with it.
• User-Assigned: A free-roaming robot you can assign to multiple machines. You create it as a standalone resource and can grant it access to a fleet of VMs or Function Apps. This is useful if you have a fleet of resources that all need the same set of permissions.

4. The Two Types of API Permissions

Once your application has an identity, you need to grant it permissions. When calling an API like Microsoft Graph, you face another fundamental choice: Delegated or Application permissions.

Imagine your application is a person you are hiring to do a job, and the API (Microsoft Graph) is a secure corporate building they need to access.

Delegated Permissions: The Personal Assistant

• What it means: The application is acting on behalf of a user who is currently logged in.
• The Analogy: You hire an assistant (the application) to help you manage your work. When the assistant needs to access a file from your office (the API), they don't have their own key. They come to you, you unlock the door with your badge (you sign in), and you let them in to work with your files.
• Effective Permissions: The actual permissions the app has are the intersection (the least privileged combination) of the user's permissions AND the app's delegated permissions. If the app has permission for Mail.ReadWrite but the signed-in user only has permission to read their own mail, the app can only read that user's mail.
• Common Use Cases:
  • Interactive applications where a user is present.
  • A mobile app that reads a user's own emails.
  • A web dashboard that shows a manager's own direct reports.
  • Any "Sign in with Microsoft" scenario.

Application Permissions: The Automated Cleaning Service

• What it means: The application is acting on its own, with its own identity. There is no human user present.
• The Analogy: You authorize an automated service (the application) to clean the entire office building every night. This service doesn't need an employee to be present to let it in. It has its own master key (a client secret or certificate) that grants it access to all the rooms it's been cleared to enter.
• Effective Permissions: The permissions granted to the application are absolute. If the app is granted Mail.Read.All, it can read every single mailbox in the organization. This is why these permissions are much more powerful and almost always require an administrator to grant consent.
• Common Use Cases:
  • Background services, daemons, and automation scripts.
  • A nightly script that scans all SharePoint sites for sensitive data.
  • An application that backs up every user's OneDrive files.

5. Putting It All Together: The Two Worlds of Permissions

A common point of confusion is where you assign these permissions. The answer depends on what you are trying to access. Think of Azure as having two distinct but connected security systems:

1. The Azure Resource Manager (ARM) World: This is about controlling access to the infrastructure itself—things you create in your Azure subscription like virtual machines, storage accounts, and key vaults. The security system here is Azure RBAC (Role-Based Access Control).
2. The Microsoft Entra ID World: This is about controlling access to data and directory services exposed via APIs, most notably the Microsoft Graph API. The security system here is OAuth 2.0 API Permissions and Consent.

Granting Permissions to Azure Resources (The ARM World)

This is the world Managed Identities were primarily built for. When you want to grant an identity permission to read a secret from a Key Vault or write a file to a Storage Account, you use Azure RBAC.

• Who can get this permission? Both regular Service Principals and Managed Identities.
• Where is this done in the GUI? On the resource itself. You go to the Storage Account or Key Vault, click on the Access control (IAM) blade, and add a role assignment. You can search for and select either a Service Principal or a Managed Identity and assign it a role like "Storage Blob Data Contributor."

Granting Permissions to APIs like Microsoft Graph (The Entra ID World)

This is the world App Registrations were primarily built for. When you want an application to read all users in your directory or send an email, you need to grant it Microsoft Graph API permissions.

• For a Service Principal: This is done in the Microsoft Entra ID portal, under App registrations. You select your application and go to the API permissions blade to request Delegated or Application permissions.
• For a Managed Identity: Historically, you could not do this in the GUI. The "App registrations" blade was built around the concept of a configurable "blueprint" and an admin consent flow that didn't apply to Managed Identities.

The Modern Way: Granting API Permissions to Managed Identities

Today, you can grant API permissions (like Microsoft Graph) to Managed Identities, which is a powerful pattern for Azure-hosted automation. However, this is primarily done programmatically using PowerShell or the Azure CLI, not through the Entra ID portal GUI.

For example, to grant a Managed Identity permission to read all users in the directory, you would use a PowerShell script to assign the User.Read.All application permission to the Managed Identity's underlying service principal.

# Get the Service Principal of your Managed Identity
$managedIdentity = Get-AzADServicePrincipal -ObjectId "your-mi-object-id"

# Get the Microsoft Graph API's Service Principal
$graphApi = Get-AzADServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"

# Get the specific "User.Read.All" application permission
$appRole = $graphApi.AppRoles | Where-Object { $_.Value -eq "User.Read.All" -and $_.AllowedMemberTypes -contains "Application" }

# Assign the permission to your Managed Identity
New-AzureADServiceAppRoleAssignment -ObjectId $managedIdentity.Id -PrincipalId $managedIdentity.Id -ResourceId $graphApi.Id -Id $appRole.Id

6. Visualizing the Identity and Permission Model

To bring these concepts together, the following diagram shows how different identity objects relate to the central concept of a Service Principal and how they receive permissions for either Azure resources (RBAC) or APIs (Graph).

---
config:
  theme: base
  look: neo
  layout: elk
---
flowchart TD
 subgraph subGraph0["Authentication Method"]
    direction LR
        AuthMI["Azure Managed
(Secret-less)"]
        AuthWIF["Workload Identity (OIDC)
(Secret-less)"]
        AuthSecret["Secret / Certificate
(Secret-based)"]
  end
 subgraph ManagedChoices["Managed Identity types"]
    direction TB
        B1["System-assigned MI
(1:1 with resource)"]
        B2["User-assigned MI
(1:M with resources)"]
  end
 subgraph Actors["Resulting Service Principals"]
    direction LR
        SP_SAMI["Service Principal
(from system-assigned MI)"]
        SP_UAMI["Service Principal
(from user-assigned MI)"]
        SP_App["Service Principal
(from App Registration)"]
  end
 subgraph RBACbox["Azure RBAC"]
        RBAC["Assign RBAC roles
on Azure resources
(e.g., Key Vault, Storage)"]
  end
 subgraph GraphPerms["Microsoft Graph Permissions"]
    direction LR
        GP_App["Application permissions
(e.g., Mail.Read.All)"]
        GP_Del["Delegated permissions
(e.g., Mail.Read)
(user present)"]
  end
    A["Where is your
code running?"] -- Inside Azure --> B["Managed Identity
(preferred)"]
    A -- Outside Azure --> C["Secret-based or Secret-less?"]
    C -- "Secret-less (Modern)" --> C_WIF["Workload Identity SPN"]
    C -- "Secret-based (Legacy)" --> C_Secret["App Registration SPN"]
    B --> B1 & B2
    B1 --> SP_SAMI & AuthMI
    B2 --> SP_UAMI & AuthMI
    C_WIF --> SP_App & AuthWIF
    C_Secret --> SP_App & AuthSecret
    SP_SAMI L_SP_SAMI_RBAC_0@-- Permissions via
Portal or CLI --> RBAC
    SP_UAMI L_SP_UAMI_RBAC_0@-- Permission via
Portal or CLI --> RBAC
    SP_App L_SP_App_RBAC_0@-- Permission via
Portal or CLI --> RBAC
    SP_App L_SP_App_GP_App_0@-- Granted to
application
Portal or CLI --> GP_App
    SP_App L_SP_App_GP_Del_0@-- "On behalf of
signed-in user
Portal or CLI" --> GP_Del
    SP_UAMI L_SP_UAMI_GP_App_0@== CLI Only ==> GP_App
    SP_SAMI L_SP_SAMI_GP_App_0@== CLI Only ==> GP_App
    n1["App Identity needed"] --> A
    AuthMI@{ shape: rounded}
    AuthWIF@{ shape: rounded}
    AuthSecret@{ shape: rounded}
    B1@{ shape: rounded}
    B2@{ shape: rounded}
    SP_SAMI@{ shape: rounded}
    SP_UAMI@{ shape: rounded}
    SP_App@{ shape: rounded}
    RBAC@{ shape: rounded}
    GP_App@{ shape: rounded}
    GP_Del@{ shape: rounded}
    A@{ shape: diam}
    B@{ shape: rounded}
    C@{ shape: diam}
    C_WIF@{ shape: rounded}
    C_Secret@{ shape: rounded}
    n1@{ shape: rounded}
    GraphPerms@{ shape: rounded}
    RBACbox@{ shape: rounded}
    Actors@{ shape: rounded}
    ManagedChoices@{ shape: rounded}
     SP_SAMI:::identity
     SP_UAMI:::identity
     SP_App:::identity
    classDef identity fill:#cde4ff,stroke:#333,stroke-width:1px
    style AuthMI stroke:#2962FF
    style AuthWIF stroke:#2962FF
    style AuthSecret stroke:#2962FF
    style B1 stroke:#2962FF
    style B2 stroke:#2962FF
    style SP_SAMI stroke:#2962FF
    style SP_UAMI stroke:#2962FF
    style SP_App stroke:#2962FF
    style RBAC fill:#BBDEFB,stroke:#2962FF
    style GP_App fill:#BBDEFB,stroke:#2962FF
    style GP_Del fill:#BBDEFB,stroke:#2962FF
    style A fill:#FFF9C4,stroke:#2962FF,stroke-width:1px
    style B fill:#e6f7ff,stroke:#2962FF
    style C fill:#ffe6d6,stroke:#2962FF
    style C_WIF fill:#e1f5fe,stroke:#2962FF
    style C_Secret fill:#fffde7,stroke:#2962FF
    style n1 fill:#FFF9C4,stroke:#2962FF,stroke-width:1px
    style GraphPerms stroke:#2962FF
    style RBACbox stroke:#2962FF
    style Actors stroke:#2962FF
    style ManagedChoices stroke:#2962FF
    style subGraph0 stroke:#2962FF
    linkStyle 0 stroke:#AA00FF,fill:none
    linkStyle 1 stroke:#AA00FF,fill:none
    linkStyle 2 stroke:#AA00FF,fill:none
    linkStyle 3 stroke:#AA00FF,fill:none
    linkStyle 4 stroke:#AA00FF,fill:none
    linkStyle 5 stroke:#AA00FF,fill:none
    linkStyle 6 stroke:#AA00FF,fill:none
    linkStyle 7 stroke:#AA00FF,fill:none
    linkStyle 8 stroke:#AA00FF,fill:none
    linkStyle 9 stroke:#AA00FF,fill:none
    linkStyle 10 stroke:#AA00FF,fill:none
    linkStyle 11 stroke:#AA00FF,fill:none
    linkStyle 12 stroke:#AA00FF,fill:none
    linkStyle 13 stroke:#AA00FF,fill:none
    linkStyle 14 stroke:#00C853,fill:none
    linkStyle 15 stroke:#00C853,fill:none
    linkStyle 16 stroke:#00C853,fill:none
    linkStyle 17 stroke:#00C853,fill:none
    linkStyle 18 stroke:#00C853,fill:none
    linkStyle 19 stroke:#D50000,fill:none
    linkStyle 20 stroke:#D50000,fill:none
    linkStyle 21 stroke:#AA00FF,fill:none
    L_SP_SAMI_RBAC_0@{ animation: none } 
    L_SP_UAMI_RBAC_0@{ animation: none } 
    L_SP_App_RBAC_0@{ animation: none } 
    L_SP_App_GP_App_0@{ animation: none } 
    L_SP_App_GP_Del_0@{ animation: none } 
    L_SP_UAMI_GP_App_0@{ animation: slow } 
    L_SP_SAMI_GP_App_0@{ animation: slow }

7. Summary: Your Practical Rule of Thumb

Choosing the right identity model is a foundational step in building secure, modern cloud applications. While the details can be complex, the decision usually boils down to one simple question: "Where is my code running?"

By defaulting to Managed Identities for all your Azure-to-Azure communication and reserving Service Principals for external workloads, you drastically reduce your attack surface and eliminate the operational nightmare of managing secrets.