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

guidoiaquinti · 2021-11-26T10:06:04Z

👋 Hi! I’m using the azure/login action for CD and I’m often getting an error when the job execution takes more than a couple of minutes from the initial login.

ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2021-11-26T09:44:41.0193003Z, expiry time of assertion 2021-11-26T09:31:56.0000000Z.

Is there a way to extend the validity of the token via a parameter? The aws-actions/configure-aws-credentials action does it via a role-duration-seconds flag:

The default session duration is 6 hours when using an IAM User to assume an IAM Role [..] . If you would like to adjust this you can pass a duration to role-duration-seconds, but the duration cannot exceed the maximum that was defined when the IAM Role was created.

ref: https://github.com/aws-actions/configure-aws-credentials/blob/master/README.md#assuming-a-role

Thank you! 🙇

The text was updated successfully, but these errors were encountered:

BALAGA-GAYATRI · 2021-12-02T08:22:44Z

@kjyam98 @N-Usha @udayxhegde Is this Doable in Azure?

udayxhegde · 2021-12-03T01:27:58Z

@BALAGA-GAYATRI I am not sure I understand the question: what is Doable in Azure? The issue seems to be that the github token has expired when it is presented to Azure AD

guidoiaquinti · 2021-12-03T08:08:36Z

@udayxhegde the problem I’m trying to solve is customise the expiration time of the token. This is useful if you plan to run operations on the Azure platform with timeframes longer than the standard validity.

Example:

Provisioning of the AKS cluster
deploy a stack
execute e2e tests
destruction of the AKS cluster

If the timeframe between steps 1 and 4 is longer than the maximum validity of the token, you will encounter an error similar to the one I posted above.

It would be useful to customise the token validity via azure/login. This is something that other cloud platforms already support.

Example:

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        role-to-assume: arn:aws:iam::123456789100:role/my-github-actions-role
        role-duration-seconds: 3600

BALAGA-GAYATRI · 2021-12-13T11:54:21Z

Hey @guidoiaquinti, This is currently not being implemented in OIDC login mechanism. If you want to leverage the auto refresh mechanism of token, you may use the SPN login by setting your deployment credentials using - https://github.com/Azure/login#configure-a-service-principal-with-a-secret
In this way you will not face token expiration issue.

guidoiaquinti · 2021-12-13T14:01:44Z

Hey @guidoiaquinti, This is currently not being implemented in OIDC login mechanism. If you want to leverage the auto refresh mechanism of token, you may use the SPN login by setting your deployment credentials using - https://github.com/Azure/login#configure-a-service-principal-with-a-secret In this way you will not face token expiration issue.

Thank you for your reply Balaga 🙇

Any plan to add this feature to the Azure roadmap? I'm trying to avoid generating and hardcoding long-term secrets if possible.

BALAGA-GAYATRI · 2021-12-14T08:51:45Z

Yes @guidoiaquinti. The refresh token mechanism is yet to be implemented.

guidoiaquinti · 2021-12-14T09:14:06Z

I understand but is there any plan to implement it?

…

On Tue, 14 Dec 2021 at 09:51, Balaga Gayatri ***@***.***> wrote: Yes @guidoiaquinti <https://github.com/guidoiaquinti>. The refresh token mechanism is yet to be implemented. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#180 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6Z3GLBB73XKGBKYRE4XC3UQ4AS3ANCNFSM5I2JEVKQ> .

BALAGA-GAYATRI · 2021-12-14T12:19:22Z

Yes. But we can't commit to a specific timeline for this right now. We will keep you informed.

github-actions · 2021-12-28T15:02:28Z

This issue is idle because it has been open for 14 days with no activity.

kjyam98 · 2022-01-28T18:00:39Z

@BALAGA-GAYATRI please assign to udayxhegde

udayxhegde · 2022-01-28T18:15:30Z

@kjyam98, that is not the right assignment

@BALAGA-GAYATRI please assign to udayxhegde

@kjyam98 , @BALAGA-GAYATRI: what are you expecting by assigning to me? did you have a specific design in mind that you need my help?

BALAGA-GAYATRI · 2022-01-31T17:32:57Z

@kjyam98, that is not the right assignment

@BALAGA-GAYATRI please assign to udayxhegde

@kjyam98 , @BALAGA-GAYATRI: what are you expecting by assigning to me? did you have a specific design in mind that you need my help?

@udayxhegde
Sorry for the confusion. This was already closed over email. We will be working with the CLI team for the changes required in CLI and in Action for the auto-refresh mechanism for addressing the same. Have assigned back the issue to my team.

github-actions · 2022-02-14T18:07:33Z

This issue is idle because it has been open for 14 days with no activity.

lpalerm · 2022-04-01T14:03:08Z

Can this be documented in the federated credentials setup steps? We are having the same issue.

github-actions · 2022-04-15T18:02:52Z

This issue is idle because it has been open for 14 days with no activity.

BartDecker · 2023-05-12T04:28:10Z

Has anyone found a workaround for the tokens that expire after ~1h? I guess you could detect that case and run the login action again?

Indeed just a re-login. We look at the average runtime of a workflow and put a re-login at the appropriate point in the workflow. Would be nice if the token time is configurable as part of the login action.

dionhaefner · 2023-05-12T09:33:18Z

I ended up just using a shell script login.sh for OIDC login (instead of the login action):

#!/bin/bash
set -e

# get JWT from GitHub's OIDC provider
# see https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc
jwt_token=$(
    curl \
        -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
        "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange" \
        --silent \
    | jq -r ".value"
)

# perform OIDC token exchange
az login \
    --service-principal -u $AZURE_CLIENT_ID \
    --tenant $AZURE_TENANT_ID \
    --federated-token $jwt_token \
    -o none

az account set \
    --subscription $AZURE_SUBSCRIPTION_ID \
    -o none

Then you can keep track of time in long-running scripts and renew the token every 50 minutes or so.

surajssd · 2023-05-17T19:24:00Z

Hit this issue on Ubuntu based workflow. We login upfront, then try to do an image build (which runs for 10-15 mins), meanwhile the token is expired and Hashicorp packer fails because the token has expired. It was only valid for 5 mins.

Here is the log from that failed step:

...
peer-pod-ubuntu.azure-arm.ubuntu: output will be in this color.

==> peer-pod-ubuntu.azure-arm.ubuntu: Running builder ...
==> peer-pod-ubuntu.azure-arm.ubuntu: Getting tokens using Azure CLI
==> peer-pod-ubuntu.azure-arm.ubuntu: unable to get token from azure cli: Invoking Azure CLI failed with the following error: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-05-17T01:01:18.0483732Z, assertion valid from 2023-05-17T00:45:33.0000000Z, expiry time of assertion 2023-05-17T00:50:33.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
==> peer-pod-ubuntu.azure-arm.ubuntu: Trace ID: 2b484d1e-c5db-483f-9502-c274b6715c00
==> peer-pod-ubuntu.azure-arm.ubuntu: Correlation ID: 97a5e8bf-8386-4f13-8db0-8cc9a18f4fad
==> peer-pod-ubuntu.azure-arm.ubuntu: Timestamp: 2023-05-17 01:01:18Z
==> peer-pod-ubuntu.azure-arm.ubuntu: Interactive authentication is needed. Please run:
==> peer-pod-ubuntu.azure-arm.ubuntu: az login
==> peer-pod-ubuntu.azure-arm.ubuntu:
Build 'peer-pod-ubuntu.azure-arm.ubuntu' errored after 1 second 393 milliseconds: Invoking Azure CLI failed with the following error: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-05-17T01:01:18.0483732Z, assertion valid from 2023-05-17T00:45:33.0000000Z, expiry time of assertion 2023-05-17T00:50:33.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
Trace ID: 2b484d1e-c5db-483f-9502-c274b6715c00
Correlation ID: 97a5e8bf-8386-4f13-8db0-8cc9a18f4fad
Timestamp: 2023-05-17 01:01:18Z
Interactive authentication is needed. Please run:
az login


==> Wait completed after 1 second 393 milliseconds

==> Some builds didn't complete successfully and had errors:
--> peer-pod-ubuntu.azure-arm.ubuntu: Invoking Azure CLI failed with the following error: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-05-17T01:01:18.0483732Z, assertion valid from 2023-05-17T00:45:33.0000000Z, expiry time of assertion 2023-05-17T00:50:33.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
Trace ID: 2b484d1e-c5db-483f-9502-c274b6715c00
Correlation ID: 97a5e8bf-8386-4f13-8db0-8cc9a18f4fad
Timestamp: 2023-05-17 01:01:18Z
Interactive authentication is needed. Please run:
az login


==> Builds finished but no artifacts were created.
make: *** [Makefile:25: podvm-c491ecd-amd64] Error 1
Error: Process completed with exit code 2.

The docs say that the expiry time is configurable. But they don't say how.

This expiration time is further configurable in Azure

YanaXu · 2023-05-31T09:33:51Z

Hi @surajssd , have you checked my comment? Have you upgraded all Azure PowerShell versions, including the manually installed one or Azure PowerShell Action?

surajssd · 2023-06-09T15:27:47Z

@YanaXu not using Powershell. Only Ubuntu/Linux based actions.

YanaXu · 2023-06-12T04:48:34Z

@surajssd , in this issue, we're talking about the Azure PowerShell login issue with OIDC with the service principle. If you do not use Azure PowerShell at all, we are meeting another issue. Let's see what's wrong in your case.
Could you share the workflow with me? You can mask the sensitive information, but let me know which actions and what general parameters you are using.

mestrada-redstage · 2023-06-27T19:55:55Z

I have this error when when the build take more that 10 min

runner: ubuntu-latest
and use manage identity for login into my AKS cluster

YanaXu · 2023-06-29T08:24:42Z

@mestrada-redstage, can you share the workflow with us?

mestrada-redstage · 2023-06-30T22:06:05Z

@YanaXu This are the steps
steps:

  - name: Checkout
    uses: actions/checkout@v3

  - name: Set env branch short name
    run: echo "BRANCH_NAME=${TRIGGER_GITHUB_REF#refs/heads/}" >> $GITHUB_ENV

  # setup Docker buld action
  - name: Set up Docker Buildx
    id: buildx
    uses: docker/setup-buildx-action@v1

  - name: Login to DockerHub
    uses: docker/login-action@v2
    with:
      registry: ${{ secrets.ACR_URL }}
      username: ${{ secrets.ACR_LOGIN }}
      password: ${{ secrets.ACR_KEY }} 

  - name: Setup anvironemnt name
    run: |
     echo "ENV_STR=${BRANCH_NAME/development/dev}" >> $GITHUB_ENV
     cat $GITHUB_ENV

  - uses: azure/login@v1
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      
  - uses: azure/use-kubelogin@v1
    with:
      kubelogin-version: 'v0.0.24'
      
  - uses: azure/setup-kubectl@v3
   
  - uses: azure/aks-set-context@v3
    with:
      resource-group: #########
      cluster-name: #######

  - name: build-deploy
    shell: bash
    run: |
      cd ${{ matrix.PROJECT_PATH }}
      chmod +x ../build.sh
      ACR_URL=${{ secrets.ACR_URL }} ACR_KEY=${{ secrets.ACR_KEY }} ACR_LOGIN=${{ secrets.ACR_LOGIN }} ../build.sh ${{ env.PROJECT_NAME }} ${{ env.TRIGGER_GITHUB_SHA }} ${{ github.event.inputs.destin }} ${{ env.PROJECT_NAME }} ${{ matrix.PROJECT_CONTEXT }}

YanaXu · 2023-07-03T05:07:15Z

@mestrada-redstage ,

In this issue, we talked about Azure PowerShell login problem with OIDC.
But your workflow seems using Azure Cli.
I think you were talking about this step which failed after 10 min.

  - name: build-deploy
    shell: bash
    run: |
      cd ${{ matrix.PROJECT_PATH }}
      chmod +x ../build.sh
      ACR_URL=${{ secrets.ACR_URL }} ACR_KEY=${{ secrets.ACR_KEY }} ACR_LOGIN=${{ secrets.ACR_LOGIN }} ../build.sh ${{ env.PROJECT_NAME }} ${{ env.TRIGGER_GITHUB_SHA }} ${{ github.event.inputs.destin }} ${{ env.PROJECT_NAME }} ${{ matrix.PROJECT_CONTEXT }}

Could you re-run this workflow with debug mode and copy the workflow's output to us?
And if it's not sensitive, please provide the content of "build.sh" too.
Thanks.

jbelien · 2023-08-10T12:55:06Z

Also hitting the same issue.
Here is the log (with debug):

##[debug]Evaluating condition for step: 'Get K8s context'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Get K8s context
##[debug]Loading inputs
##[debug]Evaluating: vars.AZURE_RESOURCE_GROUP
##[debug]Evaluating Index:
##[debug]..Evaluating vars:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'AZURE_RESOURCE_GROUP'
##[debug]=> 'rg-***'
##[debug]Result: 'rg-***'
##[debug]Evaluating: vars.AKS_CLUSTER_NAME
##[debug]Evaluating Index:
##[debug]..Evaluating vars:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'AKS_CLUSTER_NAME'
##[debug]=> 'aks-***'
##[debug]Result: 'aks-***'
##[debug]Loading env
Run azure/aks-set-context@v3
  with:
    resource-group: rg-***
    cluster-name: aks-***
    admin: false
    use-kubelogin: true
  env:
    CONTAINER_NAME: ***
    AZURE_HTTP_USER_AGENT: 
    AZUREPS_HOST_ENVIRONMENT: 
##[debug]Writing kubeconfig to /home/runner-admin/actions-runner/_work/_temp/kubeconfig_1691671866005
/usr/bin/az aks get-credentials --resource-group rg-*** --name aks-*** -f /home/runner-admin/actions-runner/_work/_temp/kubeconfig_1691671866005
ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-08-10T12:51:06.6841503Z, assertion valid from 2023-08-09T15:06:56.0000000Z, expiry time of assertion 2023-08-09T15:11:56.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
Trace ID: 070e96fc-76e1-46a8-88f7-055a0d489900
Correlation ID: 2ce46b3e-5dcf-42ed-a497-33231a9dc308
Timestamp: 2023-08-10 12:51:06Z
Interactive authentication is needed. Please run:
az login
Error: Error: The process '/usr/bin/az' failed with exit code 1
##[debug]Node Action run completed with exit code 1
##[debug]AZURE_HTTP_USER_AGENT='GitHubActions/azure/aks-set-context(6ff0b0b4611939515451a12aa8fec15e3dd86d30d7e8c0569dd2ded2113f8931; 5809746149)'
##[debug]AZUREPS_HOST_ENVIRONMENT='GitHubActions/azure/aks-set-context(6ff0b0b4611939515451a12aa8fec15e3dd86d30d7e8c0569dd2ded2113f8931; 5809746149)'
##[debug]AZURE_HTTP_USER_AGENT=''
##[debug]AZUREPS_HOST_ENVIRONMENT=''
##[debug]Finishing: Get K8s context

Azure/aks-set-context#101

hansenms · 2023-08-18T18:54:55Z

I just wanted to chime in here, we are experiencing the same problem that the client assertion expires after 5 minutes and az aks get-credentials is failing in the same way as described above. Other az commands work, so it is possible that the token is not refreshed for that command?

We use a script (along the lines of #180 (comment) by @dionhaefner) right in front of calls to az aks get-credentials in our pipelines to work around this.

mcolussi-bigw · 2023-08-24T00:29:33Z

Issue is occurring for us as well. We use null_resource terraform resources to run custom scripts that perform commands via az cli, the automated tests are failing because the token expires after 5 minutes, before the scripts execute.

Our current only work-around is to ensure the tests that run AZ cli commands run first before the token expires. 5 minutes is a very short time range to do anything useful.

JamesDawson · 2023-09-15T14:08:42Z

Are there any plans to support idTokens with a lifetime longer than 10 minutes? This constraint has sadly forced us back to using SP authentication with client secrets.

We have a scripted deployment process (i.e. runs as a single GitHub Actions step using azure/powershell@v1) that runs for longer than 10 minutes. It includes functionality towards the end that requires an access token from another service (i.e. a data plane operation), which fails as the idToken has expired.

As a tangible example of this scenario, consider using the Az.Synapse PowerShell module to make configuration changes to a Synapse Workspace that has just been provisioned by a preceding ARM deployment (lasting longer than 10 minutes).

UPDATE: When testing an equivalent repro with the recently announced preview of federated credentials for Azure DevOps, we do not see the same issue.

YanaXu · 2023-09-19T06:14:35Z

Hi @mestrada-redstage , @jbelien, @hansenms, @mcolussi-bigw , could you open another issue and provide your workflow file and the debug log? Because this issue is about the Azure PowerShell and it's fixed in Azure PowerShell 9.2 as in comment. But in your description, it seems there are other issues in Azure CLI or even other actions. Please open a new issue for your case for better tracking.

YanaXu · 2023-09-19T06:39:39Z

Are there any plans to support idTokens with a lifetime longer than 10 minutes? This constraint has sadly forced us back to using SP authentication with client secrets.

We have a scripted deployment process (i.e. runs as a single GitHub Actions step using azure/powershell@v1) that runs for longer than 10 minutes. It includes functionality towards the end that requires an access token from another service (i.e. a data plane operation), which fails as the idToken has expired.

As a tangible example of this scenario, consider using the Az.Synapse PowerShell module to make configuration changes to a Synapse Workspace that has just been provisioned by a preceding ARM deployment (lasting longer than 10 minutes).

UPDATE: When testing an equivalent repro with the recently announced preview of federated credentials for Azure DevOps, we do not see the same issue.

@JamesDawson , do you mean the toke generated by GitHub? I think it's out of the scope of this Action. Can you raise an issue for GitHub Action Core?

YanaXu · 2023-09-19T06:42:22Z

I'll close this issue.

If you meet an Azure PowerShell token expiration issue, please refer to comment .
If you meet other token expiration issues, please open a new issue for it. Provide your workflow file and debug logs for further analysis.

jbelien · 2023-11-14T12:08:10Z

Hi @mestrada-redstage , @jbelien, @hansenms, @mcolussi-bigw , could you open another issue and provide your workflow file and the debug log? Because this issue is about the Azure PowerShell and it's fixed in Azure PowerShell 9.2 as in comment. But in your description, it seems there are other issues in Azure CLI or even other actions. Please open a new issue for your case for better tracking.

Sure, I already opened an issue here: Azure/aks-set-context#101

krukowskid · 2023-11-16T08:48:53Z

hey! I am still facing this issue when running 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 am using 1.4.6 action version and 1.10.4 of azure.identity package. Problem does not occur on integration tests where almost all of them are using token, but if I am running API/UI tests where I am using identity in one or two tests it looks like token is not being refreshed if its not used for 5minutes. Any ideas or workaround?

jantorep · 2023-12-22T12:04:14Z

Any update on this case? This is driving me mad creating Enterprise Applications for our deployments.

New-AzADApplication_CreateExpanded: /home/runner/.local/share/powershell/Modules/Az.Resources/6.12.1/MSGraph.Autorest/custom/New-AzADApplication.ps1:698
Line |
698 | $app = Az.MSGraph.internal\New-AzADApplication @PSBoundParameters
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 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
| https://aka.ms/msal-net-invalid-client for details. Original exception:
| AADSTS700024: Client assertion is not within its valid time range.
| Current time: 2023-12-22T12:03:41.4945531Z, assertion valid from
| 2023-12-22T11:48:18.0000000Z, expiry time of assertion
| 2023-12-22T11:53:18.0000000Z. Review the documentation at
| https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials . Trace ID: e36c2ebe-03f4-427b-b341-9b346cd1bb00 Correlation ID: 71ce361d-10ed-4080-a049-6e15eb7bdee9 Timestamp: 2023-12-22 12:03:41Z

YanaXu · 2023-12-25T02:06:50Z

Hi @krukowskid and @jantorep , it's a closed issue. We may miss comments from a closed issue. Please check my comment for this issue. And If your issue is not solved, it means it's a new issue. Please open a new issue then, provide your workflow file, debug log for further analysis. Thanks.

justinmchase · 2024-01-25T22:43:17Z

Utmost respect for the maddest lad @dionhaefner for this comment #180 (comment)

Which allowed me to work around this issue in terraform with the following:

data "azurerm_client_config" "current" {
}

data "external" "login" {
  program = ["bash", "${path.module}/scripts/refresh.sh"]
  query = {
    client_id       = data.azurerm_client_config.current.client_id
    tenant_id       = data.azurerm_client_config.current.tenant_id
    subscription_id = data.azurerm_client_config.current.subscription_id
  }
}

#!/bin/bash
set -e

eval "$(jq -r '@sh "AZURE_CLIENT_ID=\(.client_id) AZURE_TENANT_ID=\(.tenant_id) AZURE_SUBSCRIPTION_ID=\(.subscription_id)"')"

if [[ "$ACTIONS_ID_TOKEN_REQUEST_TOKEN" == "" ]] || [[ "$ACTIONS_ID_TOKEN_REQUEST_URL" == "" ]]
then
  # This is ok, we're probably running locally
  jq -n '{}'
  exit 0
fi

# get JWT from GitHub's OIDC provider
# see https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc
jwt_token=$(
  curl "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange" \
    -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
    --silent \
  | jq -r ".value"
)

# perform OIDC token exchange
az login \
  --service-principal -u $AZURE_CLIENT_ID \
  --tenant $AZURE_TENANT_ID \
  --federated-token $jwt_token \
  -o none

az account set \
  --subscription $AZURE_SUBSCRIPTION_ID \
  -o none

jq -n '{}'

This allows me to refresh the token in the middle of a long terraform apply in a few places where I need to bust out into a null_resource or data external script and use the az cli.

module "auth_refresh" {
  source = "../../helpers/azure_auth_refresh"
}

resource "null_resource" "redirect_uris" {
  // ...
}

guidoiaquinti added the need-to-triage Requires investigation label Nov 26, 2021

guidoiaquinti mentioned this issue Nov 26, 2021

e2e - Microsoft Azure (install) PostHog/charts-clickhouse#204

Closed

6 tasks

BALAGA-GAYATRI added question The issue doesn't require a change to the product in order to be resolved. Most issues start as that and removed need-to-triage Requires investigation labels Nov 29, 2021

BALAGA-GAYATRI added product enhancement New feature or request and removed question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Dec 14, 2021

github-actions bot added the idle Inactive for 14 days label Dec 28, 2021

kaverma added the oidc label Jan 18, 2022

BALAGA-GAYATRI assigned kjyam98 Jan 28, 2022

kjyam98 removed their assignment Jan 28, 2022

github-actions bot removed the idle Inactive for 14 days label Jan 28, 2022

kaverma assigned BALAGA-GAYATRI Jan 31, 2022

github-actions bot added the idle Inactive for 14 days label Feb 14, 2022

github-actions bot removed the idle Inactive for 14 days label Apr 1, 2022

github-actions bot added the idle Inactive for 14 days label Apr 15, 2022

github-actions bot removed the idle Inactive for 14 days label May 11, 2023

YanaXu closed this as completed Sep 19, 2023

seankimkdy mentioned this issue Sep 29, 2023

[Azure] Use OIDC based authentication for GitHub Actions paraglider-project/paraglider#83

Open

krukowskid mentioned this issue Nov 21, 2023

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

Open

guotuofeng mentioned this issue Apr 8, 2024

Fix random windows CI failure microsoft/Olive#1057

Closed

6 tasks

ant0nsc mentioned this issue Apr 10, 2024

Azure login token expires while running Ubuntu GitHub workflow #432

Closed

jiasli mentioned this issue Apr 11, 2024

Azure CLI task fails with AADSTS700024 after 60 minutes Azure/azure-cli#28708

Open

sshjelle mentioned this issue Jun 25, 2024

[Bug]: ERROR: AADSTS700024: Client assertion is not within its valid time range innofactororg/bicep-action#14

Closed

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

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

Comments

guidoiaquinti commented Nov 26, 2021 • edited Loading

BALAGA-GAYATRI commented Dec 2, 2021

udayxhegde commented Dec 3, 2021

guidoiaquinti commented Dec 3, 2021 • edited Loading

BALAGA-GAYATRI commented Dec 13, 2021

guidoiaquinti commented Dec 13, 2021

BALAGA-GAYATRI commented Dec 14, 2021

guidoiaquinti commented Dec 14, 2021 via email

BALAGA-GAYATRI commented Dec 14, 2021 • edited Loading

github-actions bot commented Dec 28, 2021

kjyam98 commented Jan 28, 2022

udayxhegde commented Jan 28, 2022

BALAGA-GAYATRI commented Jan 31, 2022

github-actions bot commented Feb 14, 2022

lpalerm commented Apr 1, 2022

github-actions bot commented Apr 15, 2022

BartDecker commented May 12, 2023

dionhaefner commented May 12, 2023

surajssd commented May 17, 2023 • edited Loading

YanaXu commented May 31, 2023

surajssd commented Jun 9, 2023

YanaXu commented Jun 12, 2023

mestrada-redstage commented Jun 27, 2023

YanaXu commented Jun 29, 2023

mestrada-redstage commented Jun 30, 2023

YanaXu commented Jul 3, 2023

jbelien commented Aug 10, 2023 • edited Loading

hansenms commented Aug 18, 2023

mcolussi-bigw commented Aug 24, 2023

JamesDawson commented Sep 15, 2023 • edited Loading

YanaXu commented Sep 19, 2023

YanaXu commented Sep 19, 2023

YanaXu commented Sep 19, 2023

jbelien commented Nov 14, 2023

krukowskid commented Nov 16, 2023 • edited Loading

jantorep commented Dec 22, 2023

YanaXu commented Dec 25, 2023

justinmchase commented Jan 25, 2024

guidoiaquinti commented Nov 26, 2021 •

edited

Loading

guidoiaquinti commented Dec 3, 2021 •

edited

Loading

BALAGA-GAYATRI commented Dec 14, 2021 •

edited

Loading

surajssd commented May 17, 2023 •

edited

Loading

jbelien commented Aug 10, 2023 •

edited

Loading

JamesDawson commented Sep 15, 2023 •

edited

Loading

krukowskid commented Nov 16, 2023 •

edited

Loading