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

[guidoiaquinti]

👋 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! 🙇

[BALAGA-GAYATRI]

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

[udayxhegde]

@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]

@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:

1. Provisioning of the AKS cluster
2. deploy a stack
3. execute e2e tests
4. 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]

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]

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]

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

[guidoiaquinti]

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]

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

[github-actions]

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