I’m often surprised by how many developers and companies still rely on Client ID and Client Secret configurations when integrating with Azure Entra ID from outside Azure. While it’s true that this method is easier to configure, it comes with inherent security and maintenance challenges. In contrast, when it’s possible, Federated Identities provide a more secure and efficient approach by eliminating the need to manage secrets altogether.
In this post, I’ll walk you through a practical example using Azure DevOps, demonstrating how Federated Identities work in real-world scenarios. Then, I’ll dive into the key differences between the Client Secret approach and Federated Identities, highlighting why the latter is a better choice for a secure identity management.
If you’re looking to enhance security while simplifying identity management, this guide will help you take the first step toward adopting Federated Identities in your projects.
To better illustrate how Federated Identities work in practice, this article uses Azure DevOps as an example, where the feature is referred to as Workload Identity Federation. This is a must have feature when it comes automate deployments from Azure DevOps to any Azure Subscription. Azure DevOps provides a robust platform for managing development workflows and automation. It’s a perfect candidate to demonstrate the benefits of replacing static secrets with dynamic, short-lived tokens.
Following diagram illustrates how Workload Identity Federation works on Azure DevOps:
The fun fact when connecting Azure DevOps to Azure is that it is pretty much the same effort to configure a Client ID/Client Secret or a Federated Identity connection.
We need to set up a service connection which uses Workload Federated Identities. To create this, we must connect to Azure DevOps, and from the Service Connections Window (under Project Settings), create a new service Connection of type “Azure Resource Manager”. Then select “Workflow Identity Federation”. For this explanation, I picked a manual configuration.
In the next window, give a name to your Service Connection and optionally, you can grant the permission to use this connection to all pipelines.
In the last opening window, you will first notice two parameters : the issuer and the subject of an assertion that could be generated by Azure DevOps. At this time, you have to specify the Subscription, the Tenant and the Entra ID Service Principal ID. This last one can be an App Registration or a Managed Identity (yes, Federated Identities works with Managed Ids !). Also, at this time, you can’t create the connectivity, because you first need to set up Entra ID with Federated Credentials. Copy the issuer and subject values and connect to Azure or Entra ID to configure it.
In this example, I’m using an App Registration for the connectivity. Once you have configured your Service Connection in Azure DevOps, locate your App Registration and access to it’s “Certificates and secrets” management window. Then, select the “Federated Identity” tab.
As you can see, the Federated Identity configuration is located at the same level of the Secrets management. In fact, this is just another way to authenticate.
To configure the Federated Identity connections, click on “+ Add Credential” and select “Other Issuer” in proposed dropdown. In the appearing form, paste the “Issuer” in the “Issuer” box, paste the “Subject” in the “Value”, give a name to your credential and that’s it !
Once credentials are registered, don’t forget to save your service connections !
By the way, if you are using Managed Identities, you can do these exact same steps from the “Settings > Federated Credentials” tab of the Managed Identity.
You can find more details in Microsoft Documentation.
The Client ID and Client Secret approach has been a popular method for integrating applications with Azure Entra ID due to its simplicity: register an application, generate a secret, and use it to authenticate. However, this simplicity comes with significant drawbacks. Client secrets are static and must be securely stored by the holder. This can be challenging to enforce, especially when working with external partners. Once a secret is issued, the organization has limited control over how securely it is stored or used by the holder, increasing the risk of accidental exposure. For example, secrets might inadvertently end up hardcoded in source code, shared in unsecured channels, or stored in inadequately protected environments. And then, over time, organizations often end up managing hundreds, if not thousands, of secrets across applications, making key rotation a significant operational burden.
In contrast, Federated Identities remove the need for static secrets entirely by leveraging identity federation protocols like OpenID Connect. Applications authenticate by dynamically requesting short-lived tokens from trusted identity providers, eliminating the need for the application or its holder to manage a long-term secret. These tokens typically expire within minutes, significantly reducing the risk window, whereas Azure Entra ID tokens have a default lifetime of one hour. Federated Identities not only address security concerns but also simplify the operational burden of managing and rotating secrets, making them particularly beneficial for collaborations involving external parties or multi-cloud environments.
