Open isra-fel opened 4 months ago
Is there any progress?
Hi @igortsoi , the behavior is expected. When you run the cmdlet, our module firstly try to get the acquire the access token from the local token cache. If the cached token expires, we will try to re-authenticate automatically using the saved context information. For federated token workflow, we are do the re-authentication with the saved federated token. If the federated token also expires, you have to run Connect-AzAccounts again. And so in the case mentioned, you have to acquire the federated token and run Connect-AzAccounts for every 55 minutes. This is due to the token lifetime.
Thank you!
@msJinLei Thanks.
I performed an experiment to refresh the federated token stored in a background job (Start-Job
). See example.
Connect-AzAccount -FederatedToken
from a background job? Can this break any ongoing operations in the main script?@msJinLei Thanks.
I performed an experiment to refresh the federated token stored in a background job (
Start-Job
). See example.
- How destructive is performing
Connect-AzAccount -FederatedToken
from a background job? Can this break any ongoing operations in the main script?
The running cmdlet won't be affected. The next cmdlet will be affected if the cached access token is refreshed.
When the access token doesn't expire, you use the same applicationId, tenantId and a different federated token to connect Az.Accounts, the cached access token won't refresh.
- Is there another method to refresh the federated token stored by PowerShell Az?
What is to refresh is access token.
Please run Disconnect-AzAccount
and run Connect-AzAccount
with a new federated token again
+1 on this issue, seems the default expire time span is 1h, but we also encountered the error after 10 minutes, wondering if there is some lifetime policy for Microsoft tenant itself which caused the token expired. (I don't have permission to see the policy, just guess according to this doc: https://learn.microsoft.com/en-us/entra/identity-platform/configure-token-lifetimes
Description
Can you please help us with following issue:
We've encountered an issue potentially linked to the Az.Storage cmdlet command. A customer reported this problem within a long-running pipeline designed to store data in an Azure Storage Account, utilizing the New-AzStorageContext and Set-AzStorageBlobContent cmdlets. This process authenticates to Azure using a federated token.
According to the stack trace, an error occurs roughly 55 minutes after the script starts, coinciding with the access token's expiration. The NewAzureStorageContext function attempts to renew the token but fails, generating the following error: "Client assertion is not within its valid time range. Current time: 2024-02-28T09:53:28.3990795Z, assertion valid from: 2024-02-28T08:57:57.0000000Z, expiry time of assertion: 2024-02-28T09:07:57.0000000Z." The token, which has a 10-minute lifespan, is identified as a federated token. We suspect that New-AzStorageContext attempts to use this short-lived federated token to refresh the access token, leading to failure upon the federated token's expiration.
Is it standard practice for New-AzStorageContext to employ a federated token for refreshing the access token?
If this behavior is not anticipated, could you provide any insights into the potential causes of this issue?
Issue script & Debug output
Environment data
Module versions
Error output
No response