Service Principal & Managed Identity in Azure

Overview

In Microsoft Azure, both Service Principals and Managed Identities are used to authenticate applications and services without using a user’s credentials. The main difference is who manages the identity and credentials.

Feature	Service Principal	Managed Identity
Identity Type	Application Identity	Azure Resource Identity
Credential Management	You manage secrets/certificates	Azure manages credentials automatically
Authentication	Client ID + Secret/Certificate	No secrets required
Azure Resource Binding	Independent of Azure resources	Tied to Azure resources
Rotation of Credentials	Manual	Automatic
Best Use Case	External apps, CI/CD, multi-cloud	Azure-hosted applications

---

1. Service Principal (Application Identity)

Service Principal

A Service Principal is an identity created for an application, service, or automation tool to access Azure resources securely.

Think of it as a service account for applications.

Instead of logging in with a username and password, applications authenticate using:

• Client ID (Application ID)
• Client Secret
• or Certificate

The Service Principal is associated with an Azure AD (Microsoft Entra ID) application.

---

Architecture

Application
     |
     | Client ID + Secret
     |
Azure AD (Entra ID)
     |
     | Access Token
     |
Azure Resource
(Storage, Key Vault, SQL, etc.)

---

Authentication Flow

1. Application sends Client ID and Secret.
2. Azure AD validates the credentials.
3. Azure AD issues an OAuth access token.
4. Application uses the token to access Azure resources.

---

Advantages

• Works from anywhere (Azure, AWS, GCP, on-premises)
• Can authenticate external applications
• Supports certificates
• Suitable for automation tools

---

Disadvantages

• Secrets must be stored securely
• Secret expiration must be managed
• Credential rotation is manual
• Higher risk if secrets are exposed

---

Common Use Cases

• GitHub Actions
• Azure DevOps pipelines
• Terraform
• Jenkins
• Kubernetes outside Azure
• Applications running outside Azure

---

Example (Azure CLI)

Create a Service Principal:

az ad sp create-for-rbac --name my-app

Example output:

{
  "appId": "xxxxxxxx",
  "password": "xxxxxxxx",
  "tenant": "xxxxxxxx"
}

Login:

az login --service-principal \
-u <appId> \
-p <password> \
--tenant <tenantId>

---

Managed Identity (Azure Resource Identity)

Managed Identity

A Managed Identity is an identity automatically created and managed by Azure for an Azure resource.

No username, password, secret, or certificate is required.

Azure handles:

• Identity creation
• Credential storage
• Secret rotation
• Token acquisition

---

Architecture

Azure VM / App Service / Function
            |
            | Request Token
            |
Azure Managed Identity Endpoint
            |
            | Access Token
            |
Azure Resource
(Key Vault, Storage, SQL)

---

Authentication Flow

1. Azure resource requests a token from the Managed Identity endpoint.
2. Azure verifies the resource identity.
3. Azure issues an access token.
4. The application accesses Azure services using the token.

---

Advantages

• No secrets to store
• Automatic credential rotation
• Simplified authentication
• Lower security risk
• Easy integration with Azure services

---

Disadvantages

• Only works with Azure-hosted resources
• Cannot be used directly from local machines or external environments

---

Types of Managed Identity

System-Assigned Managed Identity

• Created automatically for a specific Azure resource.
• Lifecycle is tied to the resource.
• Deleted when the resource is deleted.
• Each resource has a unique identity.

Example:

Azure VM
    |
System Assigned Identity
    |
Key Vault

---

User-Assigned Managed Identity

• Created as a standalone Azure resource.
• Can be attached to multiple Azure resources.
• Survives even if attached resources are deleted.
• Reusable across applications.

Example:

Managed Identity
      |
  +---+----+
  |        |
 VM1      VM2
  |        |
  +--------+
      |
  Key Vault

---

Comparison

Feature	Service Principal	Managed Identity
Secrets Required	Yes	No
Secret Rotation	Manual	Automatic
Works Outside Azure	Yes	No
Azure Hosted Apps	Yes	Yes
Credential Storage	Required	Not Required
Security	Good	Better
Maintenance	Higher	Lower
Best Practice	External Applications	Azure-hosted Applications

---

Use a Service Principal when:

• Your application runs outside Azure.
• You need CI/CD authentication.
• You are using GitHub Actions.
• You are using Azure DevOps.
• You are running Terraform from a local machine.
• You need cross-cloud authentication.

---

Use Managed Identity when:

• Your application runs on Azure Virtual Machines.
• You use Azure App Service.
• You use Azure Functions.
• You use Azure Kubernetes Service (AKS).
• You access Azure Key Vault.
• You want passwordless authentication.

---

Real-World Example

Scenario 1: Azure VM Accessing Key Vault

Azure VM
    |
Managed Identity
    |
Azure AD
    |
Access Token
    |
Azure Key Vault

No secrets are stored on the VM.

---

Scenario 2: GitHub Actions Deploying to Azure

GitHub Actions
      |
Service Principal
(Client ID + Secret)
      |
Azure AD
      |
Access Token
      |
Azure Resources

GitHub is outside Azure, so a Service Principal is required.

---

Security Best Practices

For Service Principals

• Use certificates instead of client secrets when possible.
• Store secrets in Azure Key Vault.
• Rotate secrets regularly.
• Grant only the minimum required permissions (least privilege).
• Monitor sign-in logs and access.

---

For Managed Identities

• Prefer Managed Identity over Service Principals for Azure-hosted workloads.
• Use Role-Based Access Control (RBAC) with least privilege.
• Use User-Assigned Managed Identity when multiple resources need the same identity.
• Regularly review assigned roles.

---

Refer_Here for setup identity for vm