Why Should You Use Federated Identity within Azure DevOps?

For a long time, Service Principals have been the default way for Azure DevOps pipelines to authenticate with Azure. This method works but comes with long-term management headaches. Service Principals rely on secrets or certificates, which introduce security risks and operational overhead. These secrets need periodic rotation, and if they leak, they can grant unauthorized access.

Federated Identity is a better approach. Instead of storing static credentials, it lets Azure DevOps authenticate directly with Entra ID using short-lived tokens. This eliminates the need to manage secrets, reduces security risks, and simplifies maintenance.

The Problem with Service Principals

The main issue with Service Principals is that secrets must be stored somewhere. Whether they are kept in Azure DevOps, a key vault, or an external secrets manager, they still pose a risk. If someone with access - like an intern, a freelancer, or even an employee leaving the organization  - copies a secret, they might still have access to Azure resources even after their official credentials are revoked. Organizations try to reduce this risk by enforcing secret rotation policies, but that adds more administrative overhead and can cause disruptions if a secret expires unexpectedly.

Service Principal credentials also create challenges when scaling infrastructure automation. A single set of credentials is often shared across multiple pipelines, which increases the risk if it gets exposed. Managing these secrets properly is important - if a secret isn't updated in time, deployments can fail. To handle this, teams often use external tools to automate secret rotation and distribution, but that adds more dependencies and complexity. Ultimately, the problem isn't just with Service Principals - it’s with relying on static secrets in general.

How Federated Identity Solves These Issues

Federated Identity eliminates these problems by using OpenID Connect (OIDC). When a pipeline runs, Azure DevOps requests authentication from Microsoft Entra ID. Instead of using a stored credential, Entra ID verifies the request and issues a short-lived token. This token is valid only for the duration of the pipeline run and grants access only to the resources specified in its permissions. Once the pipeline finishes, the token expires automatically, reducing the risk of credential misuse.

This authentication method removes the need for long-lived credentials. Since access tokens are generated on-demand and have a limited lifespan, they do not need to be rotated manually. Unlike Service Principals, which require explicit secret updates, Federated Identity ensures that pipelines always have a valid authentication method without administrative intervention.

Security and Compliance Benefits

Using Federated Identity instead of Service Principals provides multiple security advantages. Since no credentials are stored, there is no risk of secret leaks. Tokens are valid only for a limited time, which means that even if one were exposed, it would quickly become useless. Access is granted only when needed, minimizing the risk of persistent access to resources.

Beyond security improvements, this approach also helps organizations meet compliance requirements more easily. Many security frameworks recommend avoiding long-lived credentials, and Federated Identity aligns with best practices by enforcing short-lived, scoped authentication. With no secrets to manage, there is no need for secret rotation policies or manual credential updates. Governance becomes simpler, and audits are easier since authentication events can be tracked without worrying about managing stored credentials.

Why Federated Identity is the Better Choice for Azure DevOps

Federated Identity is a more secure, scalable, and manageable authentication method for Azure DevOps pipelines. It removes the risk of leaked credentials, reduces operational overhead, and aligns with modern cloud security practices. Moving away from Service Principals and adopting Federated Identity ensures that DevOps CI/CD pipelines remain secure without the burden of managing secrets. This approach significantly enhances security when implementing an Azure DevOps pipeline for Azure CI/CD pipeline workflows.

In the next section, we will explore how this authentication method works and what happens behind the scenes when Azure DevOps requests access to Azure resources.

How Federated Identity Works within Azure

Federated Identity authentication in Azure is based on OpenID Connect (OIDC), a widely adopted authentication protocol that enables secure, token-based access without storing secrets. Instead of relying on static credentials, Azure DevOps pipelines authenticate dynamically by requesting a temporary token from Microsoft Entra ID (formerly Azure AD). This token allows access to Azure resources only for the duration of the pipeline execution, eliminating the risks associated with long-lived credentials.

When a pipeline runs in Azure DevOps, it needs to authenticate to Azure to deploy infrastructure, manage resources, or perform operational tasks. In traditional setups, this requires a Service Principal with a stored secret or certificate. With Federated Identity, the authentication flow is entirely different. The pipeline initiates a request to Microsoft Entra ID using an OIDC token. Entra ID validates the request by checking the configured Federated Credentials and issues a temporary access token if the request is approved. This token grants access only to the specific resources allowed in its permissions and expires automatically once the pipeline run is complete.

This process ensures that authentication is secure, automated, and does not depend on static secrets. Each time a pipeline runs, it generates a fresh authentication request, eliminating the need for manual secret rotation or storage. Since the token is short-lived, even if intercepted, it cannot be reused for long-term access. This approach significantly reduces the attack surface and aligns with best practices for cloud security.

The Role of Managed Identities in Federated Authentication

Federated Identity relies on Managed Identities to handle authentication. Azure provides two types of Managed Identities: System-Assigned and User-Assigned. A System-Assigned Managed Identity is tied to a specific Azure resource, such as a Virtual Machine, App Service, or Azure Kubernetes Service (AKS). When the resource is deleted, the identity is also removed. This type of identity is useful for workloads running within Azure but is not ideal for Azure DevOps pipelines that need a reusable authentication mechanism.

User-Assigned Managed Identities, on the other hand, are independent of any single resource and can be assigned to multiple services. This makes them the preferred choice for Azure DevOps pipelines. A User-Assigned Managed Identity acts as a persistent, reusable identity that pipelines can use to authenticate to Azure without requiring stored credentials. By associating Federated Identity Credentials with a User-Assigned Managed Identity, Azure DevOps can authenticate dynamically whenever a pipeline runs.

How Azure DevOps Requests and Receives a Token

For Azure DevOps to authenticate using Federated Identity, it follows a structured process:

1. Pipeline Execution Begins
   
   • The pipeline is triggered, requiring authentication to access Azure resources.
   • Instead of using a stored secret, it initiates an authentication request to Microsoft Entra ID.
2. Microsoft Entra ID Validates the Request
   
   • The request includes metadata, including a signed OIDC token from Azure DevOps.
   • Entra ID verifies the Issuer, Subject, and Audience values to ensure it comes from an authorized source.
3. A Temporary Access Token is Issued
   
   • If the validation succeeds, Microsoft Entra ID generates a short-lived access token.
   • This token is scoped to allow access only to the required Azure resources.
4. Azure DevOps Uses the Token to Authenticate
   
   • The pipeline uses the token to access Azure services such as Virtual Machines, Storage Accounts, or Kubernetes clusters.
   • The token expires automatically once the pipeline execution is completed.
5. Token Expiry Enhances Security
   
   • Since each token is generated on-demand, there are no long-lived secrets to manage.
   • The next time the pipeline runs, a new authentication request is initiated.

This process ensures that each authentication event is unique, temporary, and scoped only to the necessary resources, reducing security risks.

Understanding Issuer, Subject, and Audience in Federated Identity

For Federated Identity authentication to work correctly, specific parameters must be configured in Microsoft Entra ID when setting up Federated Credentials. These values define how Azure DevOps pipelines can request and receive access tokens.

Issuer

The Issuer identifies the entity generating the authentication request. In the case of Azure DevOps, the Issuer is always:

https://token.actions.githubusercontent.com

•  Microsoft Entra ID checks this value to verify that the authentication request originates from Azure DevOps.

Subject

The Subject defines which pipeline is making the request. It includes the Azure DevOps organization, project, and service connection name, formatted as follows:

system:serviceaccount:{organization}:{project}:azure-service-connection

•  This ensures that only the designated pipeline within a specific project is authorized to authenticate.

Audience

The Audience parameter specifies where the issued token will be used. For Azure DevOps pipelines, this is set to:

api://AzureADTokenExchange

•  This prevents the token from being used outside of the expected scope, enhancing security.

Properly configuring these values in Microsoft Entra ID makes sure that only the intended pipelines receive authentication tokens and that no unauthorized entity can impersonate them.

Why Federated Identity Works Best for Azure DevOps Pipelines

The shift from Service Principal authentication to Federated Identity with Managed Identities aligns with modern security best practices. With this approach, pipelines authenticate without storing secrets, reducing the attack surface and eliminating the risks of secret exposure. Since each authentication request is validated in real-time, access is granted only when needed, reducing the likelihood of persistent unauthorized access.

This method also simplifies compliance and governance. Security teams no longer have to enforce secret rotation policies, and authentication logs provide a clear audit trail of which pipelines accessed which resources. Organizations following Zero Trust security principles benefit from the fact that access tokens are ephemeral and scoped to a single pipeline execution.

Federated Identity makes Azure DevOps authentication secure, scalable, and fully automated. In the next section, we will go through the step-by-step setup of Federated Identity in Azure, including how to create a User-Assigned Managed Identity, assign permissions, and configure Federated Credentials in Microsoft Entra ID.

How to Set Up Federated Identity in Azure?

Integrating Federated Identity with Azure DevOps allows pipelines to authenticate securely without storing secrets. Instead of using Service Principal credentials, authentication is handled dynamically through Microsoft Entra ID (formerly Azure AD). The first step in this setup is to create a User-Assigned Managed Identity (UAMI), assign Role-Based Access Control (RBAC) permissions, and configure Federated Credentials in Microsoft Entra ID.

A User-Assigned Managed Identity is independent of any specific resource and can be assigned to multiple services, making it ideal for Azure DevOps pipelines. Unlike system-assigned identities, which are tied to a single resource, user-assigned identities persist even when a resource is deleted. This ensures continuous authentication for pipelines.

Creating a User-Assigned Managed Identity

Now, to create a User-Assigned Managed Identity, navigate to the Azure Portal, go to Managed Identities, and select Create a User-Assigned Managed Identity. Choose the subscription and resource group, provide a meaningful name, and select a region. Once the identity is created, it will appear under Managed Identities.

After the identity is created, it must be granted the necessary permissions to access Azure resources. This is done by assigning RBAC roles. In the Azure Portal, navigate to the identity, go to Azure role assignments, and add a new role. Select the appropriate scope - either at the Subscription, Resource Group, or Resource level. The recommended roles depend on the actions the pipeline needs to perform. For most scenarios, Contributor is appropriate.

Configuring Federated Credentials in Microsoft Entra ID

With the Managed Identity and permissions set up, the next step is to configure Federated Credentials in Microsoft Entra ID. This establishes a trust relationship between Azure DevOps and Microsoft Entra ID, allowing pipelines to authenticate dynamically.

In the Microsoft Entra ID portal, go to the User-Assigned Managed Identity you created, select Federated Credentials, and add a new credential. The correct Issuer, Subject, and Audience values must be defined:

• Issuer: https://dev.azure.com/{organization}
• Subject: system:serviceaccount:{organization}:{project}:azure-service-connection
• Audience: api://AzureADTokenExchange

The Issuer must match your Azure DevOps organization URL, and the Subject must reference the correct Azure DevOps project and service connection.

How to Configure Azure DevOps to Use Managed Identity?

Now that the Federated Identity is set up in Microsoft Entra ID, the next step is to configure Azure DevOps to use this authentication method. This requires creating a Service Connection that allows Azure DevOps pipelines to authenticate using the Managed Identity.

In Azure DevOps, navigate to Project Settings, then go to Service Connections, and select New Service Connection. Choose Azure Resource Manager, then select Managed Identity as the authentication method.

When configuring the service connection, select Subscription or Resource Group as the scope, depending on what level of access is required. Choose the User-Assigned Managed Identity that was created earlier to complete the setup. Once saved, this service connection allows Azure DevOps pipelines to authenticate without requiring stored secrets.

To verify the setup, test the service connection by running a basic Azure CLI command in a temporary pipeline. If authentication succeeds, the pipeline can access Azure resources using the Federated Identity.

How to Run an Azure DevOps Pipeline with Federated Identity?

With authentication configured, it's time to create an Azure DevOps pipeline that uses Federated Identity to access Azure resources. This pipeline will log in to Azure using the Managed Identity, list resource groups, and deploy an Azure resource.

First, create a new repository in Azure DevOps to store the pipeline configuration. Navigate to Repos, create a repository, and add a new file named .azure-pipelines.yml.

Inside the repository, create the pipeline YAML file with the following configuration:

This pipeline logs in using the Managed Identity and lists the available resource groups in the subscription. Commit this file to the repository.

Now, let’s deploy an Azure Storage Account using Terraform. In the same repository, create a new file named main.tf and add the following configuration:

After committing the Terraform configurations, navigate to Pipelines in Azure DevOps, create a new pipeline, and select Azure Repos Git as the source. Choose the repository where the YAML file is stored and let Azure DevOps detect the configuration.

Once the pipeline is set up, run it to deploy the infrastructure. The terraform apply output should look similar to the following:

Next, navigate to Pipelines, create a new pipeline, and select Azure Repos Git as the source. Choose the repository where the YAML file is stored and allow Azure DevOps to detect and use the configuration.

Once the pipeline is set up, run it to verify authentication. The output should display a list of resource groups, confirming that the Federated Identity is working correctly.

Now, to verify that Federated Identity is being used correctly in the Azure DevOps pipeline, we can check the Azure CLI logs. When authentication is successful using Federated Credentials, the logs should indicate that the pipeline is using a federated token rather than a stored secret or certificate.

The confirmation in the logs typically appears during the Azure CLI login step. It should show that authentication is happening via Managed Identity and include the flag --federated-token.

In the Azure DevOps pipeline run logs, you should see output similar to the following:

In these logs you should check for: 

• The presence of --federated-token in the az login command confirms that the pipeline is not using a stored secret.
• The "type": "servicePrincipal" confirms that authentication is happening via an identity managed by Microsoft Entra ID.
• The "tenantId" should match the Microsoft Entra ID tenant where the Federated Identity Credentials were configured.

This verification makes sure that Azure DevOps pipelines are authenticating dynamically and securely using Federated Identity, without storing credentials.

Best Practices for Integrating Federated Identity Credentials with Azure DevOps

Now, Federated Identity removes credential management risks, but to strengthen the  security and reliability of your workflow, here are some of the best practices that you should follow.

Enforce Least Privilege Access with RBAC

Granting excessive permissions to Managed Identities can lead to security risks. Instead of assigning broad roles like Owner or Contributor, use least privilege principles to grant only the necessary permissions. For example, if a pipeline only needs to deploy infrastructure, assign the Managed Identity Operator role instead of full subscription-level access. Use custom roles if built-in roles do not fit your access control needs.

Monitor Authentication Logs and Audit Access

Regularly reviewing authentication logs is important for identifying potential security risks. Azure provides built-in monitoring tools such as Azure Monitor, Microsoft Entra ID Sign-in Logs, and Azure DevOps Auditing to track authentication attempts. Set up alerts for unusual activity, such as repeated failed authentications or unexpected access from unknown locations.

Use Conditional Access Policies for Additional Security

Microsoft Entra ID allows enforcing Conditional Access Policies to restrict access to specific users, locations, or risk-based conditions. Applying these policies ensures that only trusted sources can request authentication tokens. For example, you can restrict token issuance to specific Azure DevOps projects or require Multi-Factor Authentication (MFA) for manual approvals.

Rotate and Revalidate Federated Credentials Periodically

While Federated Identity eliminates the need for secret rotation, it is still good practice to review and update credentials periodically. Revoking old credentials and revalidating access ensures that only authorized pipelines have authentication privileges. Automate this process using Azure Policy to enforce periodic revalidation.

Integrate Federated Identity with Kubernetes (AKS)

For teams running Azure Kubernetes Service (AKS), Federated Identity can be extended to workloads inside clusters. Azure’s Workload Identity for Kubernetes allows pods to authenticate using Managed Identities, following the same principles as Azure DevOps pipelines. This eliminates the need for Kubernetes secrets to store credentials and enables a consistent authentication model across CI/CD and runtime environments.

Standardizing Authentication Across Multi-Cloud Environments

For organizations operating in a multi-cloud setup, Federated Identity can be standardized across AWS, GCP, and Azure. By implementing OIDC-based authentication across different cloud platforms, teams can use a single authentication mechanism for accessing cloud resources. This reduces complexity and avoids the need for separate identity management solutions per provider.

Firefly Workspaces: Enhancing Your CI/CD Pipelines

Setting up Federated Identity for authentication in Azure DevOps pipelines is a significant step forward for security. It eliminates stored credentials, making sure that every authentication event is temporary and scoped. However, this setup involves multiple steps, and when something breaks, debugging can be challenging. A misconfigured role, an incorrect issuer, or even a missing permission can halt the pipeline, leaving DevOps teams scrambling to diagnose and resolve the issue.

While Federated Identity strengthens authentication, securing a CI/CD pipeline requires more than identity federation. Pipelines need continuous security enforcement, infrastructure visibility, and policy compliance. Even with Federated Identity in place, misconfigurations, unintended changes, and security gaps can still occur. This is where Firefly makes a difference.

Firefly integrates directly into Azure DevOps pipelines to enhance Terraform workflows by providing real-time insights before infrastructure changes are applied. Instead of relying on terraform plan, Firefly visualizes infrastructure dependencies, mapping out how resources are connected. This level of visibility makes sure that teams understand exactly what will be created, modified, or deleted before running terraform apply, reducing the risk of unexpected changes breaking infrastructure. By surfacing these insights early, Firefly helps teams make informed decisions and maintain stability across deployments.

Beyond visibility, Firefly enforces security and policy compliance at the Terraform deployment level using shift-left security principles. Security checks happen early in the development process, allowing teams to identify and address risks before infrastructure changes reach production. This proactive approach prevents last-minute surprises and makes sure that your infrastructure remains compliant with security and operational policies.

Firefly introduces Guardrails, automated security and compliance checks that integrate directly into CI/CD workflows. These Guardrails act as pre-deployment checkpoints, ensuring Terraform deployments align with security requirements before execution. Unlike traditional monitoring tools that only alert after an issue has occurred, Firefly’s Guardrails proactively prevent misconfigurations and security risks from making it to production.

However, security enforcement alone isn’t enough. In fast-moving DevOps environments, blocking a deployment due to a policy violation can cause delays in CI/CD workflows, slowing down release cycles and disrupting engineering teams. Firefly goes beyond enforcement by offering AI-powered remediation to help teams resolve issues efficiently.

Now, when a Guardrail blocks a misconfiguration, Firefly’s AI-powered remediation suggests actionable fixes. Instead of leaving engineers to manually investigate and troubleshoot, Firefly provides context-aware recommendations based on best practices. With a single click, teams can apply these AI-generated fixes, ensuring compliance without slowing down deployments.

Firefly makes sure that your infrastructure remains secure and compliant without disrupting workflow efficiency. Rather than reacting to security incidents after they occur within the prod environment, teams can prevent them from happening in the first place.

Firefly doesn’t just enhance Terraform deployments - it transforms how security, compliance, and automation work together in modern DevOps pipelines. With full visibility into infrastructure changes, automated policy enforcement, and intelligent remediation, Firefly enables teams to scale with confidence while maintaining a secure and efficient cloud environment.

To learn more about Firefly’s features, explore their docs and blogs, and try Firefly yourself to see how it enhances your DevOps workflows.

Frequently Asked Questions 

How can I trigger an Azure DevOps pipeline automatically on code changes?‍

Use CI triggers in azure-pipelines.yml with trigger: [branch-name], or configure a GitHub webhook to start the pipeline on push events.

How do I pass secrets securely in Azure DevOps pipelines?

Store secrets in Azure Key Vault and link it to the pipeline, or use Pipeline Variables (secret scope) to keep them encrypted and hidden.