Service Principal vs Managed Identity

 Service Principal

We can say the most relevant part of the Service principal is the Enterprise Apps section under Azure Active Directory. This is basically an application that will allow your user apps to authenticate and access Azure resources, based on the RBAC.

It essentially is an ID of an application that needs to access Azure resources. In layman’s terms, imagine if you have to assign certain access to your colleague so that he\she can access Azure resources and perform required tasks, you can use their email id as a way to authenticate the user.

Managed Identity

We can say that the Managed Identities are actually Service Principals and they are identical in the functionality and purpose they serve.

The only difference is, that a managed identity is always linked to an Azure Resource, unlike an application or 3rd party connector mentioned above. They are automatically created for you, including the credentials; big benefit here is that no one knows the credentials

There are two types of managed identities:

1.) System assigned; in this scenario, the identity is linked to a single Azure Resource, eg a Virtual Machine, a Web App, Function,… so almost anything. Next, they also “live” with the Azure Resource, which means they get deleted when the Azure Resource gets deleted.

2.) User Assigned Managed Identity, which means that you first have to create it as a stand-alone Azure resource by itself, after which it can be linked to multiple Azure Resources. An example here could be out of integration with the Key Vault, where different Workload services belonging to the same application stack, need to read out information from Key Vault. In this case, one could create a “read KV” Managed Identity, and link it to the web app, storage account, function, logic app,… all belonging to the same application architecture.