login: ERROR: AADSTS700024: Client assertion is not within its valid time range

Hi! I am facing a similar issue (#180) that appears to have been resolved, but I’m still encountering this problem when executing dotnet tests in GitHub Runner.

Azure.Identity.CredentialUnavailableException : DefaultAzureCredential failed to retrieve a token from the included credentials. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/defaultazurecredential/troubleshoot
- Azure CLI authentication failed due to an unknown error. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/azclicredential/troubleshoot ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-10-31T11:53:04.4424859Z, assertion valid from 2023-10-31T11:39:49.0000000Z, expiry time of assertion 2023-10-31T11:44:49.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials . Trace ID: d64c537e-1d94-4274-9012-c0d7590f1c00 Correlation ID: 5c769bb7-e85a-4557-ba28-92f8eca1c4ff Timestamp: 2023-10-31 11:53:04Z
	Interactive authentication is needed. Please run:
	az login

I’m using action version 1.4.6 and azure.identity package version 1.10.4 + DefaultAzureCredential(). The issue doesn’t occur on integration tests where nearly all of them utilize tokens. However, if I run API/UI tests where I employ identity in one or two tests, it fails with above error. Do you have any suggestions or workarounds?

About this issue

  • Original URL
  • State: open
  • Created 7 months ago
  • Reactions: 12
  • Comments: 32 (5 by maintainers)

Commits related to this issue

Most upvoted comments

❗ ❗ ❗If you are encountering ERROR: AADSTS700024: Client assertion is not within its valid time range, here are the workarounds for four scenarios:

  1. If your workflow fails after 5 minutes recently with azure-cli on your runner upgraded to 2.59.0:

    Workaround: Downgrade azure-cli to 2.58.0. Following are the scripts to downgrade the azure-cli version on your agent.

    • If you are using azure/cli action, specify azcliversion with an older version of Azure CLI below 2.59.0, such as 2.58.0.
      - uses: azure/cli@v2
          azcliversion: 2.58.0
          inlineScript: |
            az --version
    • If you are using other actions depending on azure-cli, downgrade azure-cli on Linux runners:
            runs-on: ubuntu-latest
               - name: uninstall azure-cli 
                 run: |
                    sudo apt-get remove -y azure-cli
               - name: install azure-cli 2.58.0
                 run: |
                    sudo apt-get update
                    sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release
                    sudo mkdir -p /etc/apt/keyrings
                    curl -sLS https://packages.microsoft.com/keys/microsoft.asc |
                        sudo gpg --dearmor -o /etc/apt/keyrings/microsoft.gpg
                    sudo chmod go+r /etc/apt/keyrings/microsoft.gpg
                    AZ_DIST=$(lsb_release -cs)
                    echo "Types: deb
                    URIs: https://packages.microsoft.com/repos/azure-cli/
                    Suites: ${AZ_DIST}
                    Components: main
                    Architectures: $(dpkg --print-architecture)
                    Signed-by: /etc/apt/keyrings/microsoft.gpg" | sudo tee /etc/apt/sources.list.d/azure-cli.sources
                    sudo apt-get update && sudo apt-get install azure-cli=${AZ_VER}-1~${AZ_DIST}
               - name: check azure-cli version
                 run: |
                    az --version
    • Downgrade azure-cli on Windows runners:
          runs-on: windows-latest
             - name: uninstall azure-cli 
               run: |
                  Start-Process msiexec.exe -Wait -ArgumentList '/x {DEFB65A7-FD02-4710-B01E-6C9387982CA9} /quiet'
             - name: install azure-cli 2.58.0
               run: |
                  $ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -Uri https://azcliprod.blob.core.windows.net/msi/azure-cli-2.58.0-x64.msi -OutFile .\AzureCLI.msi; Start-Process msiexec.exe -Wait -ArgumentList '/I AzureCLI.msi /quiet'; Remove-Item .\AzureCLI.msi
             - name: check azure-cli version
               run: |
                  az --version

    Note that downgrading Azure CLI may take some time to finish. But this workaround is only necessary until Azure CLI 2.60.0 is released.

  2. If your workflow fails after 5 minutes also in azure-cli <= 2.58.0:

    • This is because there is no access token for your requested scope in the token cache, Azure CLI will try to get the access token with the GitHub ID token. However, as the ID token has expired after 5 minutes, you will encounter ERROR: AADSTS700024. See https://github.com/Azure/azure-cli/issues/28708#issuecomment-2047256166.
    • It is expected to be solved after azure-cli supports ID token refresh.

    Workaround: Request access token with all your required scopes within 5 minutes. Here are the most popular requested scopes. Modify the script according to your request.

      - uses: azure/cli@v2
          azcliversion: 2.58.0
          inlineScript: |
              # Storage:
              az account get-access-token --scope https://storage.azure.com/.default --output none 
              # Key Vault: 
              az account get-access-token --scope https://vault.azure.net/.default --output none
              # Microsoft Graph: 
              az account get-access-token --scope https://graph.microsoft.com/.default --output none
              # Kusto: 
              az account get-access-token --scope https://kusto.kusto.windows.net/.default --output none
  3. If your workflow fails after 60 minutes: This is because azure-cli can only request an access token with a lifetime of 60 minutes. But ID token has expired after 5 minutes, azure-cli cannot get a new access token after 60 minutes. It is expected to be solved after azure-cli supports ID token refresh.

    Workaround: Use user managed identities with OIDC, instead of using service principals The token lifetime of managed Identities would be 24 hours, see Managed identities tokens cache. This can cover the lifetime for most of the CI/CD workflows.

  4. If your workflow fails after 5 minutes with azure-powershell < 9.2: This is the scenario what #180 talks. It’s fixed in Azure PowerShell v9.2 (released on 12/6/2022). See https://github.com/Azure/login/issues/180#issuecomment-1524995605.

Check your scenario and use the provided workaround. We’re actively working to resolve this issue. Thank you for your understanding.

I don’t know why but I can’t replicate it anymore. However if you are still curious on how my workflow looks like :

name: Test Workflow for Debugging Azure Cli Credentials Timeout


  id-token: write
  contents: read

    name: "Testing Azure Cli Timeout"
    runs-on: [self-hosted, linux, x64] # ubuntu-latest
    environment: Production
      - name: Install Azure cli
        run: |
          sudo apt-get install ca-certificates curl apt-transport-https lsb-release gnupg -y
          curl -sL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/microsoft.gpg > /dev/null
          AZ_REPO=$(lsb_release -cs)
          echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $AZ_REPO main" | sudo tee /etc/apt/sources.list.d/azure-cli.list
          sudo apt-get update
          sudo apt-get install azure-cli

      - name: Az CLI login
        uses: azure/login@v1
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          allow-no-subscriptions: true

      - name: Sleep for 10 minutes
        run: sleep 600

      - name: Az CLI Account Show
        run: az account show

what I’m suspecting is that for the ubuntu runner we are using, azure cli might have been updated ? (I’m not sure which version of ubuntu we are running, but it might be that azure cli latest was not yet the right version for our distrib ?)

A nice solution with automatic periodic refresh has been suggested in https://github.com/Azure/azure-cli/issues/28708#issuecomment-2049014471 which you can wrap in a custom github action like show below. Can potentially be used as a temporary replacement of this action for long running workflows.

name: Azure Federated Login

    description: Azure client id
    type: string
    description: Azure tenant id
    type: string
    description: Azure subscription id
    type: string
    default: none
    description: Refresh interval in seconds
    type: number
    default: 240

  using: "composite"
    - name: Fetch OID token every ${{ inputs.refresh-interval-seconds }} seconds
      shell: bash
      run: |
        while true; do
          token=$(curl -s -H "Authorization: bearer ${ACTIONS_ID_TOKEN_REQUEST_TOKEN}" "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=api://AzureADTokenExchange" | jq .value -r)
          az login --service-principal -u ${{ inputs.client-id }} -t ${{ inputs.tenant-id }} --federated-token $token --output none
          if [ "$first_time" = true ] && [ "${{ inputs.subscription-id }}" != "none" ]; then
            az account set -s ${{ inputs.subscription-id }}
          sleep ${{ inputs.refresh-interval-seconds }}
        done &

I am the developer of Azure CLI for federated identity credential support. Please see https://github.com/Azure/azure-cli/issues/28708#issuecomment-2047256166 for a temporary mitigation to extend the task duration to 60 minutes.

We’ve recently been experiencing this issue, it was working fine before, and no changes have been made to the workflow.


  • Runner using the ubuntu-latest image.
  • azure/login using OIDC login.
  • run steps calling the Azure CLI directly.

We noticed that the issue arose when the GitHub hosted runner image went from 20240324.2.0 to 20240407.1.0. The PR shows that the Azure CLI was updated from 2.58.0 to 2.59.0, see https://github.com/actions/runner-images/pull/9656/files#diff-66aec6097318276b09842a3ba2caf3037afbd8dadca2dfcdf76631100613ea69R111.

I’m not aware of nice workarounds for now, so I’ll add more azure/login steps…

use this work around detailed previously:

token=$(curl -H "Authorization: bearer {token_request}" "{token_uri}&audience=api://AzureADTokenExchange" | jq .value -r) 
az login --service-principal -u {CLIENT_ID} -t {TENANT_ID} --federated-token $token')

you can create a timer to call this every 5 minutes or you can simply do this every iteration (or every other iteration, etc)

you can also use runspaces to finish everything 10x faster or smth

thats what i was using and its definitely isnt working with OIDC

@benjamin-rousseau-shift i think the issue is with the underlying OIDC token issued by Github (5 minutes expiry). it seems like its not a fault of Azure Cli. I’ve started having issues similar to yours after migrating to federated identity. I solved them:


I’m using python, but you can implement this fix in any other language:

def get_azure_credentials():
    token_request = os.environ.get("ACTIONS_ID_TOKEN_REQUEST_TOKEN")
    token_uri = os.environ.get("ACTIONS_ID_TOKEN_REQUEST_URL")
    subprocess_helper(f'token=$(curl -H "Authorization: bearer {token_request}" "{token_uri}&audience=api://AzureADTokenExchange" | jq .value -r) && az login --service-principal -u {CLIENT_ID} -t {TENANT_ID} --federated-token $token')
    return AzureCliCredential()

same issue here this is a real pain. The token are only valid for 5 minutes, and if you don’t use it until very far in your workflow, then it just throw the error shown by OP

I tried azure/login@1.5.0 same issue. I’m not using any other way to login into azure.

Hi @krukowskid , could you provide the workflow file, run it again with debug mode, and provide the debug log?