Table of contents

Introduction

There are several ways for a service to authenticate in Azure. There is no single one-size-fits-all approach. Instead, there are multiple options, and in some scenarios, combining methods is technically possible as well. Each approach has its own advantages and disadvantages. In this article, I outline and compare the most relevant options.

System-assigned Managed Identity

System-assigned Managed Identity is a native Azure capability that gives a service an identity it can use to access other resources. Typically, you first enable the System-assigned Managed Identity, which creates an Enterprise Application in Entra ID. This identity can then be granted permissions on other resources. A service with an enabled System-assigned Managed Identity usually uses that identity automatically, or can be configured to do so with minimal effort.

Advantages:

• Managed Identity is fully integrated into Azure.
• There are no expiring secrets or similar credentials that require regular updates.
• Deprovisioning is also handled cleanly (if the Azure resource with an enabled Managed Identity is deleted, the related Enterprise Application in Entra ID is deleted as well).

User-assigned Managed Identity

In Azure, it is also possible to create a separate identity object and assign it to an application. In practice, a User-assigned Managed Identity behaves similarly to a Managed Identity and is very practical, but it is only supported by specific Azure services.

Why would you choose a User-assigned Managed Identity?

• Multiple Azure services should operate under the same identity.
• Decoupling between the Azure service and the identity (which can be useful for specific scenarios or tests).

Disadvantage:

• The object created in Azure must be deleted manually when it is no longer needed. (With a System-assigned Managed Identity, the identity in Entra ID is removed automatically when the resource is deleted.)

App Registration (Federated credentials)

In an App Registration in Entra ID, you can configure Federated credentials. An overview of how this works can be found here: Overview of federated identity credentials in Microsoft Entra ID. One major advantage is that there are no secrets to manage, and therefore no secrets that can expire. Especially in operations, this can significantly improve stability.

There are limitations, though, as described here: Add and manage application credentials in Microsoft Entra ID. The following systems are supported:

• Customer managed keys
• GitHub Actions deploying Azure resources
• Kubernetes accessing Azure resources
• Other issuer

App Registration (Client secrets and Certificates)

Besides Federated credentials, an App Registration can also use Client Secrets or Certificates. The downside of this method is that you must manage a credential (either a string in the case of Client Secrets, or a certificate). These credentials cannot live forever. Entra enforces a maximum lifetime (for good security reasons).

However, this lifecycle topic adds operational overhead and must be handled continuously. If a secret expires, the application can no longer authenticate and will at least be partially impaired.

Summary

The following table lists all methods by preferred order (lower number is better).