How to Use Service Principals and Managed Identities in Azure for Secure and Seamless Authentication

If you are developing applications or services that need to access Azure resources, such as storage accounts, databases, or key vaults, you need to consider how to authenticate and authorize your applications or services. One of the best practices for securing your Azure resources is to use Azure Active Directory (Azure AD), which is a cloud-based identity and access management service that provides identity and access management for your applications, users, and devices.

However, Azure AD offers different ways to authenticate and authorize your applications or services, such as service principals and managed identities. What are the differences between them and how do you choose the best option for your scenarios?

In this post, we will explain what service principals and managed identities are, how they work, and how to use them in your applications or services.

What are service principals and managed identities?

Service principals and managed identities are both types of application identities that represent your applications or services in Azure AD. They both allow your applications or services to access Azure resources that are secured by Azure AD. However, they have some key differences that you should be aware of:

Service principal: A service principal is an identity that you create and manage in Azure AD for your application or service. You need to register your application or service in Azure AD and assign it a service principal. You also need to generate a client secret or a certificate for your service principal and store it securely in your application or service. You can then use the service principal with the client secret or the certificate to authenticate your application or service to Azure AD and obtain an access token that can be used to access Azure resources.
Managed identity: A managed identity is an identity that is automatically created and managed by Azure for your application or service. You do not need to register your application or service in Azure AD or generate any client secret or certificate for it. You only need to enable a managed identity for your application or service on the Azure resource where it is hosted, such as a virtual machine, an app service, a function app, etc. You can then use the managed identity to authenticate your application or service to Azure AD and obtain an access token that can be used to access Azure resources.

How do service principals and managed identities work?

Service principals and managed identities work differently in terms of how they authenticate and authorize your applications or services to access Azure resources. Here are some of the main differences:

Authentication: Service principals require you to use the Azure AD authentication libraries (such as Microsoft Authentication Library (MSAL) or Azure SDKs) in your application or service code to authenticate to Azure AD using the client secret or the certificate of your service principal. Managed identities do not require you to use any authentication libraries in your code. Instead, they use the Azure Instance Metadata Service (IMDS), which is a REST endpoint that is available on every Azure resource where a managed identity is enabled. You can simply send a HTTP request to the IMDS endpoint from your application or service code to obtain an access token using the managed identity.
Authorization: Service principals and managed identities both require you to assign roles or permissions to them in order to access Azure resources. Roles or permissions define what actions a service principal or a managed identity can perform on a specific Azure resource. You can assign roles or permissions to a service principal or a managed identity using the Azure portal, the Azure CLI, the Azure PowerShell, or the Azure Resource Manager templates.

How to use service principals and managed identities in your applications or services?

The choice between service principals and managed identities depends largely on your application or service scenarios and requirements. Here are some factors that can help you decide which option is best suited for your needs:

Simplicity: If you want to simplify the authentication and management of your application or service identity, managed identities may be a better option for you. Managed identities do not require you to register your application or service in Azure AD, generate any client secret or certificate, store them securely, rotate them periodically, etc. You only need to enable a managed identity for your application or service on the Azure resource where it is hosted and use a simple HTTP request to obtain an access token.
Flexibility: If you want to have more flexibility and control over the authentication and management of your application or service identity, service principals may be a better option for you. Service principals allow you to register your application or service in Azure AD, generate any client secret or certificate, store them in any secure location, rotate them as needed, etc. You can also use service principals with any authentication protocol or library that is supported by Azure AD, such as OpenID Connect, OAuth 2.0, MSAL, etc.
Portability: If you want to have more portability and compatibility for your application or service identity, service principals may be a better option for you. Service principals can be used on any platform or environment where your application or service is hosted, such as on-premises, cloud, hybrid, etc. You can also use service principals with any application or service that can communicate with Azure AD, such as third-party or custom applications or services. Managed identities can only be used on Azure resources where they are enabled and with Azure services that support them.

Here is a simple example of how to use a service principal and a managed identity in a C# application that accesses an Azure Storage account:

using Azure.Identity;
using Azure.Storage.Blobs;

// Create a blob client using a service principal
var clientId = "your-service-principal-client-id";
var clientSecret = "your-service-principal-client-secret";
var tenantId = "your-azure-ad-tenant-id";
var credential = new ClientSecretCredential(tenantId, clientId, clientSecret);
var blobClient = new BlobClient(new Uri("https://your-storage-account.blob.core.windows.net/your-container/your-blob"), credential);

// Create a blob client using a managed identity
var credential = new DefaultAzureCredential();
var blobClient = new BlobClient(new Uri("https://your-storage-account.blob.core.windows.net/your-container/your-blob"), credential);

using Azure.Identity;

using Azure.Storage.Blobs;

// Create a blob client using a service principal

var clientId = "your-service-principal-client-id";

var clientSecret = "your-service-principal-client-secret";

var tenantId = "your-azure-ad-tenant-id";

var credential = new ClientSecretCredential(tenantId, clientId, clientSecret);

var blobClient = new BlobClient(new Uri("https://your-storage-account.blob.core.windows.net/your-container/your-blob"), credential);

// Create a blob client using a managed identity

var credential = new DefaultAzureCredential();

var blobClient = new BlobClient(new Uri("https://your-storage-account.blob.core.windows.net/your-container/your-blob"), credential);

Conclusion

Service principals and managed identities are both types of application identities that enable you to authenticate and authorize your applications or services to access Azure resources that are secured by Azure AD. However, they have some key differences in terms of how they are created and managed, how they authenticate to Azure AD, and how they are assigned roles or permissions. You should evaluate your scenarios and requirements and compare the benefits and limitations of both options to find the best fit for your needs.