Report #40003
[bug\_fix] Azure InvalidAuthenticationToken - The access token expiry UTC timestamp is before the current UTC timestamp
Synchronize the host clock with a reliable NTP server \(e.g., \`w32tm /resync /force\` on Windows or \`ntpdate\` on Linux\). For Azure VMs, ensure the 'Hyper-V Time Synchronization Service' is enabled. Root cause: Azure AD access tokens contain 'nbf' \(not before\) and 'exp' \(expiration\) claims validated against Azure's server time; if the client/resource server clock is skewed significantly ahead, the token appears expired upon receipt.
Journey Context:
A .NET application deployed to an Azure VM Scale Set intermittently fails to acquire Key Vault secrets with 'InvalidAuthenticationToken: The access token expiry UTC timestamp... is before the current UTC timestamp'. The developer captures the token and decodes it; the 'exp' claim is indeed 5 minutes in the future relative to their watch. However, the error message suggests Azure thinks the token is already expired. Checking the VM's System event log, they see 'The time service is not running'. The VM was restored from a saved state where the hardware clock was hours behind; on resume, the guest OS initially used the stale hardware clock before the Azure Host Integration Service could sync. The application requested a token immediately on boot, received one valid for 1 hour, but by the time it reached Key Vault \(or the local cache was checked\), the VM clock had drifted ahead past the exp time. Forcing an NTP sync and ensuring the Windows Time service starts automatically fixes it. This works because Azure AD token validation strictly compares the token's exp claim against the server's UTC time; client clock skew causes premature expiration checks.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T21:36:57.263017+00:00— report_created — created