Azure DevOps: AZURE_FEDERATED_TOKEN not injected in pipeline using Workload Identity Federation

Question

Azure DevOps: AZURE_FEDERATED_TOKEN not injected in pipeline using Workload Identity Federation

Matthew Holmes 20

Effectively the same problem as here:
https://learn.microsoft.com/en-us/answers/questions/2241454/azure-devops-azure-federated-token-not-injected-in

Getting the error "The workload identity configuration wasn't provided in environment variables or through WorkloadIdentityCredentialOptions."

The login to Azure via the federated SP works
Oauth enabled on the ADO Organization
Agent is windows-latest
App registration was created by azure devops and federated credentials it inserted look correct.

Bodapati Harish 820 Reputation points Microsoft External Staff Moderator

2025-06-09T17:47:07.86+00:00
Hello Matthew Holmes,

That error means the Azure SDK expects three things: your tenant ID, your client ID, and a federated token file, but can’t find them in the environment. To fix this, start by editing your Azure Resource Manager service connection under Project Settings → Service connections and switch it to Workload Identity Federation (manual). Copy the exact Issuer URL shown there (any extra slash or different casing will prevent token issuance) and paste it into the Federated credentials section of your Entra ID app registration.

Next, replace any classic login steps in your YAML with an AzureCLI@2 task that has addSpnToEnvironment: true. This setting injects the OIDC values servicePrincipalId, idToken, and tenantId into your environment. Inside that task, you will confirm they are present, perform the federated login, and then verify the account:

trigger: branches: include: - main pool: vmImage: 'windows-latest' variables: azureSubscription: 'My-Fed-SP-Connection' steps: - checkout: self - task: AzureCLI@2 displayName: 'Login with federated Service Principal' inputs: azureSubscription: '$(azureSubscription)' addSpnToEnvironment: true scriptType: bash scriptLocation: inlineScript inlineScript: | # confirm the OIDC environment variables are present env | grep -E 'servicePrincipalId|idToken|tenantId' # perform the federated login az login --service-principal \ --username $servicePrincipalId \ --federated-token $idToken \ --tenant $tenantId # show the signed-in account to prove it worked az account show

Make sure you run on a hosted agent image such as windows-2022 or ubuntu-20.04+ so the Azure CLI supports the --federated-token switch. Also confirm your DevOps organization has been onboarded for OIDC token injection (preview feature) and that the service principal has the proper RBAC role (for example Contributor) on the subscription or resource group you need to manage. With those pieces in place, the federated token will flow into your pipeline automatically and your login step will succeed every time. If you have any further questions, please reply back.
Matthew Holmes 20 Reputation points

2025-06-09T18:05:35.3066667+00:00

Hi Bodapati, where do I check that the "Azure DevOps organization has been onboarded for OIDC token injection"?

Accepted answer

1 additional answer

Your answer

Matthew Holmes 20 Reputation points

2025-06-09T18:05:35.3066667+00:00

Hi Bodapati, where do I check that the "Azure DevOps organization has been onboarded for OIDC token injection"?

Answer 1

Hello Matthew Holmes,

I was happy to repost the solution you shared, and I’m glad it helped resolve your issue. Thank you for taking the time to document your workaround so that others facing the same problem can find an easy reference.

To make sure the .NET SDK picks up your federated token reliably in Azure Pipelines, write the $idToken into the agent’s temporary directory and then export the three required environment variables before running any database migrations or other SDK calls.

For example, in your AzureCLI@2 or PowerShell task:


# write the OIDC JWT into a temp file

$tokenPath = "$(Agent.TempDirectory)\federated-token.jwt"

Set-Content -Path $tokenPath -Value $env:idToken

# export the values the SDK needs

$env:AZURE_CLIENT_ID            = $env:servicePrincipalId

$env:AZURE_TENANT_ID            = $env:tenantId

$env:AZURE_FEDERATED_TOKEN_FILE = $tokenPath

With those three variables in place, WorkloadIdentityCredential (used by Microsoft.Data.SqlClient and other Azure SDK libraries) will automatically find and use your token file for authentication. No further changes are required.

Answer 2

Microsoft suddenly stopped injecting into the agent the correct environment variables and also the token that normally gets written toC:/var/run/secrets/azure/tokens/azure-identity-token

The environment variables in question are the ones used in, for example, Microsoft.Data.SqlClient which is inside entity framework for connecting to the database for database migrations when the connection string has Authentication=Active Directory Workload Identity;'

So I manually did the below mapping and saving of the token to work around the issue by using the CLI task with addSpnToEnvironment set. Below is the mapping

$env:AZURE_CLIENT_ID = $env:servicePrincipalId

$env:AZURE_TENANT_ID = $env:tenantId

Set-Content -Path "C:\.idtoken" -Value $env:idToken

$env:AZURE_FEDERATED_TOKEN_FILE = "C:\.idtoken"

Bodapati Harish 820 Reputation points Microsoft External Staff Moderator

2025-06-10T14:56:53.0266667+00:00

Hi Matthew Holmes,

Thanks for the update, please check the private message window once

Share via

Azure DevOps: AZURE_FEDERATED_TOKEN not injected in pipeline using Workload Identity Federation

1 additional answer

Your answer