Azure DevOps Workload Identity Federation Explained: A Deep Dive

With the growing need for secretless, secure, and scalable authentication methods in CI/CD pipelines, Azure DevOps has introduced a powerful feature called Workload Identity Federation. This approach allows Azure DevOps pipelines to authenticate to Azure without using secrets, by leveraging industry-standard protocols like OAuth 2.0 and OpenID Connect (OIDC).

In this article, we’ll dive deep into how it works, why it’s needed, and how it enables federated access even when you’re using Managed Identities — which are already secretless.

The Problem with Traditional Service Connections

Historically, when an Azure DevOps pipeline needed to access Azure resources, you had to:

1. Create an App Registration in Entra ID (formerly Azure AD).
2. Generate a Client Secret.
3. Configure a Service Connection in Azure DevOps using the app’s Client ID and Secret.

During pipeline execution, DevOps would pass this secret to Entra ID, receive an access token, and then use it to call Azure APIs.

Why This Is Problematic

- Secrets can leak
- Secrets expire and need rotation
- Managing them introduces operational overhead

So while this method works, it’s not ideal in a zero-trust, passwordless world.

Enter OAuth 2.0 and OpenID Connect

Before understanding Workload Identity Federation, it’s critical to understand the protocols that enable it: OAuth 2.0 and OpenID Connect (OIDC).

OAuth 2.0: Authorization Protocol

- OAuth 2.0 is about authorization, not identity.
- It enables one service (e.g., Azure DevOps) to act on behalf of a user or service to access resources (e.g., Azure ARM).
- It uses Access Tokens to grant this access.

OpenID Connect (OIDC): Authentication Layer on Top of OAuth

- OIDC builds on top of OAuth 2.0 to add authentication.
- It introduces the ID Token (JWT format) that asserts who the caller is.
- It helps validate identity of the requestor using claims, subject identifiers, and signature.

Used Together

- OIDC issues the ID Token for authentication.
- OAuth then exchanges this token to get an Access Token for authorization.

This pairing is exactly what makes Azure DevOps Workload Identity Federation secure and effective.

Azure DevOps Workload Identity Federation: How It Works

Instead of using stored secrets, Azure DevOps now acts as an OIDC-compliant identity provider. Here’s what happens:

1. Azure DevOps issues an OIDC ID token at pipeline runtime.
2. The token includes:
  - Issuer: https://vstoken.dev.azure.com/{organization}
  - Subject: A unique identifier combining project/pipeline/service connection
  - Audience: api://AzureADTokenExchange
3. This token is sent to Entra ID (Azure AD).
4. Entra ID validates the token using well-known endpoints and public signing keys.
5. If the token matches a Federated Credential configuration in Entra ID, it issues an Access Token scoped to the target Azure resource.

The Access Token is then used to perform operations on Azure, just like in the secret-based approach.

Two Implementation Modes: Automatic vs. Manual

Workload Identity Federation in Azure DevOps can be configured in two ways:

1. Automatic Mode (Recommended) – Azure DevOps handles federation behind the scenes.
2. Manual Mode (Managed Identity) – You manually configure federation for fine-grained control.

Let’s explore both.

1. Automatic Mode (Recommended for Most Cases)

When you create a new Azure Resource Manager (ARM) service connection in Azure DevOps, the portal now offers:

✅ Automatic Workload Identity Federation setup (recommended option).

How It Works

1. Behind the scenes, Azure DevOps:
  - Creates an App Registration in Entra ID (Azure AD).
  - Configures federated credentials for the pipeline.
  - Manages token exchange automatically.

1. You only need to:
  - Select your Azure subscription.
  - Grant RBAC permissions (e.g., Contributor).
  - No manual App Registration or secret management!

When to Use Automatic Mode?

✔ Quick setup (best for new pipelines).
✔ No existing Managed Identity requirement.
✔ You want Azure DevOps to handle federation.

Example: A new team setting up CI/CD for an Azure Web App can use Automatic Mode to avoid manual federation setup.

2. Manual Mode (For Managed Identities)

If you already use Managed Identities (User-Assigned or System-Assigned) in Azure, you can manually federate them with Azure DevOps.

How It Works

1. You manually configure:
  - - A Federated Credential on the Managed Identity.
    - The Service Connection in Azure DevOps (using manual mode).
2. Required settings:
  - Issuer: https://vstoken.dev.azure.com/{org}
  - Subject: sc://{org}/{project}/{service-connection-name}
  - Audience: api://AzureADTokenExchange

When to Use Manual Mode (managed ID Mode) ?

✔ Reusing existing Managed Identities (e.g., for Terraform, Bicep deployments).
✔ Strict RBAC requirements (e.g., pre-assigned permissions on a UAMI).
✔ Enterprise scenarios where identities are centrally managed.

Example: A company using Terraform with a pre-configured User-Assigned Managed Identity (UAMI) would choose Manual Mode to avoid creating a new App Registration.

Comparison: Automatic vs. Manual Mode

Feature	Automatic Mode	Manual Mode
Setup Complexity	Low (Azure DevOps handles it)	Medium (Manual federated credential setup)
Best For	New pipelines, quick starts	Existing Managed Identities, custom RBAC
Identity Type	App Registration (auto-created)	User-Assigned/System-Assigned Managed Identity
Maintenance	Fully managed by Azure DevOps	Requires manual updates if pipeline changes

Recommendation :
– Start with Automatic Mode for simplicity.
– Switch to Manual Mode if you need Managed Identity integration.

Converting Old Secret-Based Connections

This process involves upgrading existing Azure DevOps service connections that use client secrets to the new Workload Identity Federation model. It removes the stored secret and replaces it with secure, short-lived tokens issued via OIDC.

Azure DevOps provides a one-click convert option in the portal and also supports bulk conversion using scripts.

- Azure DevOps UI provides a “Convert” option
- Microsoft provides scripts to bulk convert existing connections
- No pipeline rewrite needed — only the auth mechanism changes

Key Benefits

- 🔐 No secrets stored or rotated
- ✅ Native integration with Entra ID and RBAC
- 🛡️ Least-privilege control at pipeline level
- 🔁 Works with both App Registrations and Managed Identities
- 📦 Standardized with OAuth + OIDC

Real-World Use Case: Terraform Deployment with Workload Identity Federation

Let’s consider a real-world scenario where an organization uses Terraform in Azure DevOps pipelines to deploy Azure infrastructure. The team wants to eliminate the use of stored secrets and leverage Workload Identity Federation to authenticate Terraform directly with Azure.

📁 Goal

- Use a federated identity instead of a service principal secret to authenticate Terraform with Azure.
- Deploy a resource group using Terraform via Azure DevOps pipeline.

🔧 Setup Steps

1. Create a User Assigned Managed Identity (UAMI) in Azure.
2. Assign RBAC roles to this identity — e.g., Contributor on the target subscription or resource group.
3. Configure a Federated Credential on the UAMI:
  - Issuer: https://vstoken.dev.azure.com/{org}
  - Subject: sc://{org}/{project}/{service-connection}
  - Audience: api://AzureADTokenExchange
4. In Azure DevOps, create a Service Connection using:
  - Manual configuration
  - Client ID and Tenant ID of the UAMI
  - Matching Issuer and Subject as configured in Azure
5. Terraform Pipeline YAML Snippet:
```
trigger:
  branches:
    include:
      - main

pool:
  vmImage: ubuntu-latest

variables:
  ARM_CLIENT_ID: '<Client-ID-of-UAMI>'
  # No client secret required when using federated identity
  ARM_TENANT_ID: '<Tenant-ID>'
  ARM_SUBSCRIPTION_ID: '<Subscription-ID>'
  ARM_USE_OIDC: true # Enables Workload Identity Federation


steps:
- task: AzureCLI@2
  inputs:
    azureSubscription: '<Federated-Service-Connection-Name>'
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: |
      terraform init
      terraform plan
      terraform apply -auto-approve
```
  💡 Terraform automatically picks up the OIDC token issued by Azure DevOps and exchanges it with Azure using the federated credential.

✅ Result

- No secrets are stored in the pipeline.
- Terraform securely authenticates to Azure using the OIDC token exchange mechanism.
- The pipeline acts as the Managed Identity with proper RBAC permissions.

📓 About `main.tf`

No changes are required in main.tf to support Workload Identity Federation. The Azure provider in Terraform automatically picks up credentials from environment variables set in the pipeline (ARM_CLIENT_ID, ARM_TENANT_ID, ARM_USE_OIDC=true). Your resource definitions and provider block remain the same.

Azure DevOps Workload Identity Federation is not just an enhancement — it’s a fundamental shift towards modern, secure, passwordless CI/CD authentication.

When used with Managed Identities, it enables pipelines running outside Azure to securely represent Azure-native identities — without a single secret ever stored.

Automatic Token Refresh: Keeping Connections Secure

The Problem: Short-Lived Tokens

Azure access tokens typically expire after 1 hour. In traditional authentication:

- Long-running pipelines would fail when tokens expired
- Required complex workarounds to refresh tokens manually
- Created security gaps with extended token lifetimes

The Solution: Automatic Refresh

Workload Identity Federation automatically handles token refresh by:

- Silently renewing OIDC tokens before expiration
- Exchanging them for fresh Azure access tokens
- Requiring zero configuration – enabled by default

What You Need to Do

Nothing ! This feature:

- Works out-of-the-box with all federated connections
- Applies to both Automatic and Manual modes
- Can be monitored in Azure AD audit logs if needed

Example: A 3-hour Terraform apply will seamlessly get new tokens without pipeline failures or manual intervention.

Universal Compatibility: Federation & Token Refresh Across Azure Tools

Workload Identity Federation and its automatic token refresh work consistently across all Azure deployment tools:

How It Works for Every Tool

Federation Support

- Terraform: Set ARM_USE_OIDC=true
- Bicep/ARM: Native Azure deployments
- Azure CLI: az login --federated-token
- Azure PowerShell: Connect-AzAccount
- Azure SDKs: DefaultAzureCredential

Token Refresh Benefits

- ✅ All tools get fresh tokens
- 🔄 Auto-renewal before expiration
- 🔐 No changes needed in your code
- ⚡ Continuous long-running operations

Technical Why It Works

1. Azure DevOps handles OIDC token refresh (independent of tool)
2. Azure AD issues new access tokens to any authenticated request
3. Your tool receives valid tokens throughout execution

Real-World Example: A 4-hour Bicep deployment or Terraform apply will automatically:

Get new OIDC tokens every 5-10 minutes

Receive fresh Azure access tokens hourly

Complete without authentication failures

Tool	Federation Support	Auto-Refresh
Terraform	✅ Yes (ARM_USE_OIDC)	✅ Fully automatic
Bicep	✅ Native	✅ Fully automatic
Azure CLI	✅ –federated-token	✅ Fully automatic
PowerShell	✅ Connect-AzAccount	✅ Fully automatic

The Problem with Traditional Service Connections

Why This Is Problematic

Enter OAuth 2.0 and OpenID Connect

OAuth 2.0: Authorization Protocol

OpenID Connect (OIDC): Authentication Layer on Top of OAuth

Used Together

Azure DevOps Workload Identity Federation: How It Works

1. Automatic Mode (Recommended for Most Cases)

How It Works

When to Use Automatic Mode?

2. Manual Mode (For Managed Identities)

How It Works

When to Use Manual Mode (managed ID Mode) ?

Comparison: Automatic vs. Manual Mode

Converting Old Secret-Based Connections

Key Benefits

Real-World Use Case: Terraform Deployment with Workload Identity Federation

📁 Goal

🔧 Setup Steps

✅ Result

📓 About main.tf

Automatic Token Refresh: Keeping Connections Secure

The Problem: Short-Lived Tokens

The Solution: Automatic Refresh

What You Need to Do

Universal Compatibility: Federation & Token Refresh Across Azure Tools

How It Works for Every Tool

Federation Support

Token Refresh Benefits

Technical Why It Works

Rate this:

Share this:

Related

Leave a comment Cancel reply

📓 About `main.tf`