Skip to main content

Solving Azure DevOps Workload Identity Federation service connection 50 minute time-out error

 When connecting to external resources like Azure Resource Manager you will need a service connection in Azure DevOps. Normally I utilize a service principal for this purpose. The certificate issued by Microsoft Entra ID was normally valid for two years but Microsoft changed this to three months in the release of January 18th and is promoting the usage of Workload identity federation (WIF).

When testing this WIF based service connection I noticed that the OIDC token is only valid for about 50 minutes. This time is to short for the PowerShell script I use to monitor the Azure Image Builder image builds. These image build processes can take up to four hours but fail now with an error message like the one below.

A configuration issue is preventing authentication - check the error message from the server for details. You can modify the configuration in the application registration portal. See for details.  Original exception: AADSTS700024: Client assertion is not within its valid time range. Current time: 2024-01-22T17:33:11.8833126Z, assertion valid from 2024-01-22T16:43:00.0000000Z, expiry time of assertion 2024-01-22T16:52:59.0000000Z. Review the documentation at

At this moment there is not much information available. The best information related to my issue I found in a Terraform related post and an excellent article of Emanual Palm called Azure Workload Identity Federation which contained the information I needed for solving this OIDC token time-out issue.

To solve the issue I had to switch from the AzurePowerShell@5 step to the AzureCLI@2 task. This is needed to have access to the OIDC token which is added when you use the addSpnToEnvironment setting.

- task: AzureCLI@2
  displayName: 'OIDC token renewal'
    azureSubscription: ''
    scriptType: 'pscore'
    scriptLocation: 'scriptPath'
    scriptPath: 'Invoke-RenewOidcToken.ps1'
      -AccessToken $(System.AccessToken)
    addSpnToEnvironment: true

The Invoke-RenewOidcToken PowerShell script contains the logic to retrieve a new OIDC token by calling the Azure DevOps REST oidctoken endpoint (using the pipeline access token for the authorization) and it changes the idToken environment variable to extend the session. The script contains also a 4 hour run test cycle to prove that the script can run longer than 50 minutes.

param (

# The service connection ID can be found stored in any of the environment variables named ENDPOINT_DATA_<ServiceConnectionId>_<Something>URL.
try {
    $ServiceConnectionId = (Get-ChildItem -Path Env: -Recurse -Include ENDPOINT_DATA_*)[0].Name.Split('_')[2]
catch {
    throw "Unable to determine service connection ID."

# Set up an URI for the Azure DevOps API endpoint to get the OpenID Connect token from.
$IdTokenUri = "${env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI}${env:SYSTEM_TEAMPROJECTID}/_apis/distributedtask/hubs/build/plans/${env:SYSTEM_PLANID}/jobs/${env:SYSTEM_JOBID}/oidctoken?serviceConnectionId=${ServiceConnectionId}&api-version=7.1-preview.1"

function Set-IdToken {
    $Response = Invoke-RestMethod -Headers @{
            Authorization  = "Bearer $AccessToken"
            'Content-Type' = 'application/json'
        } `
        -Uri $IdTokenUri `
        -Method Post

    # Renew the OpenID Connect token.
    $env:idToken = $Response.oidctoken
    # Sign-in to Azure to activate the renewed token.
    az login --service-principal --username $env:servicePrincipalId --tenant $env:tenantId --federated-token $Response.oidctoken
    Write-Host "The OpenID Connect token has been renewed."

$MaxRepeat = 120

# The ID token expires every 50 minutes. Given a waiting period of 120 seconds it should be renewed every 25 cycles.
$RenewalCycle = 25
$RenewalCounter = 0

if (-not $IsFinished) {
    do {

        if ($RenewalCounter -eq $RenewalCycle) {
            $RenewalCounter = 0

        Write-Host "Waiting 120 seconds. Retries left: $MaxRepeat"
        Start-Sleep -Seconds 120

    } until ($MaxRepeat -eq 0)


Popular posts from this blog

CS8357: The specified version string contains wildcards, which are not compatible with determinism.

Today I was busy with creating a WCF service solution in Visual Studio Enterprise 2017 (15.9.2). In this solution I use a few C# class libraries based on .NET 4.7.2. When I compiled the solution I got this error message: Error CS8357: The specified version string contains wildcards, which are not compatible with determinism. Either remove wildcards from the version string, or disable determinism for this compilation The error message is linking to my AssemblyInfo.cs file of the Class library projects. In all the projects of this solution I use the wildcard notation for generating build and revision numbers. // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.

Fixing HTTP Error 401.2 unauthorized on local IIS

Sometimes the Windows Authentication got broken on IIS servers so you cannot log in locally on the server. In that case you get the dreadfully error message HTTP Error 401.2 - Unauthorized You are not authorized to view this page due to invalid authentication headers. To fix this issue you can repair the Windows Authentication feature with the following PowerShell commands: Remove-WindowsFeature Web-Windows-Auth Add-WindowsFeature Web-Windows-Auth

Assign an existing certificate to your IIS website with WiX

Recently I had to change the bindings of existing IIS hosted websites and APIs from HTTP to HTTPS. They are installed with a MSI file created with the WiX Toolset . Because I have to use an already on the server installed certificate I cannot use the Certificate element from the IIS Extension because this element only supports installing and uninstalling certificates based on PFX files. After doing some research I found the blog article Assign Certificate (Set HTTPS Binding certificate) to IIS website from Wix Installer which described the usage of Custom Actions for this purpose. I adopted this approach and rewrote the code for my scenario. With WiX I still create the website. <iis:WebSite Id="WebSite" ConfigureIfExists="yes" AutoStart="yes" Description="MyWebsite" Directory="IISROOT" StartOnInstall="yes"> <iis:WebAddress Id="WebSite"