Managed identity vs. service principal for Azure apps

Managed identities

A managed identity in Microsoft Entra ID enables Azure services to authenticate to other Azure resources without securely managing credentials. It automatically provides an identity that can obtain Entra ID tokens. This process eliminates the need for hardcoded credentials, which enhances security and simplifies authentication and authorization.

Two options are available for managed identities:

1. System-assigned managed identity.
2. User-assigned managed identity.

What is a system-assigned managed identity?

A system-assigned managed identity is created automatically with an Azure service instance, such as a VM or web app. The identity is tied to that resource, making it easy to manage but not shareable. For example, because the identity shares the same lifecycle as the service, deleting the service also deletes the identity.

This type of identity works best when a single resource needs access to other Azure resources and requires minimal management.

A system-assigned managed identity has the following attributes:

• Created automatically.
• Identity lifecycle tied to the service.
• Requires minimal management.
• Best for a single resource.

What is a user-assigned managed identity?

An Azure resource with a user-assigned managed identity operates independently, and users can assign the identity to one or more service instances. A user creates the identity manually as a standalone resource and manages it separately from any service instance. The identity persists until it's explicitly deleted.

This resource proves helpful when multiple resources share the same identity. It's also beneficial when users require more flexibility and control over the identity's lifecycle management.

In summary, a user-assigned managed identity has the following characteristics:

• Created independently.
• Can be shared across multiple resources.
• Greater control over management.
• Requires manual deletion.

Benefits of using managed identities

Managed identities in Azure eliminate the need for manual credential management, limit the risk of human error and reduce credential leaks. They enhance security by automatically handling the identity lifecycle and simplifying authentication for Azure services. For example, a managed identity can securely authenticate a VM to access Azure Key Vault without storing or embedding credentials in the application.

Users can create role assignments via Azure role-based access control (RBAC) to define an identity's permission for accessing resources. Azure Monitor and Azure Activity Logs help track identity usage and access patterns, as well as implement policies for compliance and governance.

Service principals

A service principal is a security identity within Microsoft Entra ID that enables applications, hosted services and automated tools to access Azure resources securely. It functions similarly to a user identity, but it represents an application or service that needs to authenticate and be authorized to access specific resources instead of a human user.

Service principals enable applications to sign in and perform tasks with minimal privileges, ensuring secure operations.

Three main types of service principals are available in Azure:

1. Application service principal. Application service principals are created when an application is registered with Microsoft Entra ID. They represent the application across its deployments and enable it to authenticate and access resources in Azure or Microsoft Entra ID.
2. Managed identity service principal. Enabling a managed identity on Azure creates a managed identity service principal. This type of principal simplifies credential management by providing an identity for the application to connect to resources that support Azure authentication.
3. Legacy service principal. These principals are older methods that often involve manual management for credentials, such as passwords or certificates. Organizations typically use these in environments where modern authentication mechanisms are not feasible.

How to create and manage service principals

Use Azure CLI and PowerShell cmdlets to create a new application and its corresponding service principal in Microsoft Entra ID. Azure automatically provisions managed identity service principals when users enable managed identity on Azure services. It also handles all management. Legacy service principals require manual setup and credential management.

Service principals use Azure RBAC to define access and permissions, with roles assignable at various levels, such as subscriptions or resource groups. Clients authenticate using secrets or certificates, which users should securely store and rotate, preferably in Azure Key Vault. Monitor and audit through Azure Monitor and Azure Activity Logs to ensure compliance.

Benefits of using service principals

Service principals in Azure offer key benefits in both security and automation. They provide granular access control, ensuring specific permissions and minimizing damage if compromised. Different applications or services have distinct identities and support isolation, which prevents a breach in one from affecting others.

Service principals also enable automation tools, such as Azure DevOps, Jenkins and Terraform, to authenticate and manage resources in CI/CD pipelines without manual intervention. These tools can also help secure scripted operations and integrate with Azure RBAC, which simplifies permission management and updates as applications evolve.

Differences between managed identities and service principals

Understanding the differences between managed identities and service principals is crucial for choosing the appropriate authentication method for Azure resources. While both enable applications and services to access Azure resources securely, they have distinct characteristics and use cases.

Managed identities simplify credential management, as Azure automatically handles and rotates them. Service principals require manual handling of client secrets or certificates, which must be securely stored and rotated.

In lifecycle and scope, users can assign managed identities as either system-assigned (for a single resource) or user-assigned (shareable across resources). Meanwhile, users can create and delete service principals independently, offering finer access control.

Managed identities suit Azure-native resources, while service principals fit external apps or services that need Azure interaction.

For security, managed identities enhance safety by avoiding credential exposure, with Azure managing rotation. In contrast, service principals demand strict credential management to mitigate risks.

When to use each

The decision to use managed identities or service principals depends on several factors. Use managed identities when an application or service runs within Azure. Azure can handle credential management automatically and minimizes the risk of credential exposure. Managed identities also simplify the authentication process and automate identity management, which reduces administrative effort.

Service principals are best when the application or service runs outside Azure. It's necessary to automate tasks or scripts that interact with Azure resources or require more granular control over permissions and access levels. Service principals are also necessary for integrating with external services or third-party applications. They require secure credential handling and ongoing management but offer more flexibility for external applications.

Both methods support Azure RBAC for access control, though service principals are better for external use. Managed identities simplify compliance with minimal credential exposure, while service principals need stricter policies to meet regulations such as GDPR or HIPAA.

Real-world scenarios

An example use case for managed identity is when Azure Functions needs to read from Azure Queue Storage and write to Azure Cosmos DB. Users enable a system-assigned managed identity for the function and assign the necessary roles in Azure RBAC. This simplifies authentication and eliminates credential management, with Azure handling security and credential rotation.

For a service principal, imagine a DevOps pipeline in a third-party CI/CD tool deploying to Azure. Users can create a service principal in Microsoft Entra ID, assign roles such as contributor and securely store its credentials in the CI/CD tool. This setup enables the tool to authenticate and automate Azure resource management securely.

Conclusion

It's crucial to secure access to resources in cloud computing. Microsoft Azure offers two essential authentication methods: managed identities and service principals. Managed identities are best for internal Azure resources, and they provide seamless, secure authentication without credential management. Service principals are necessary for external applications or automation tasks that require detailed access control.

Liam Cleary is founder and owner of SharePlicity, a technology consulting company that helps organizations with internal and external collaboration, document and records management, business process automation, automation tool deployment, and security controls and protection. Cleary's areas of expertise include security on the Microsoft 365 and Azure platforms, PowerShell automation and IT administration. Cleary is a Microsoft MVP and a Microsoft Certified Trainer.