Clock Skew

Clock skew is a difference in clock readings between systems, such as an application server and an identity provider. Clock drift is related but distinct: it is the rate at which a clock gains or loses time, potentially creating skew. Cloud authentication depends on reasonably synchronized clocks because signed requests, temporary credentials, federation assertions, and tokens have time-based validity conditions.

For example, an application can possess the correct AWS access key and secret key yet fail to authenticate because its AWS Signature Version 4 request contains a timestamp too far from the service's current time. Errors such as RequestTimeTooSkewed, RequestExpired, or a signature-not-yet-current message can indicate a time problem, depending on the service. Accepted timestamp windows vary by protocol and service; there is no universal AWS clock-skew allowance. Some SDKs compensate for detected skew when signing subsequent requests, but that does not synchronize the operating system or fix other authentication protocols.

Federation introduces additional clocks. A SAML assertion has validity conditions such as NotBefore and NotOnOrAfter. If an external identity provider's clock is incorrect, IAM Identity Center federation or an AWS STS AssumeRoleWithSAML request can fail even when certificates, role mappings, and user assignments are correct. IAM Identity Center permission sets determine access after authentication; changing a permission set does not repair an assertion that is outside its validity period.

Applications validating Amazon Cognito JWTs must evaluate expiration and any applicable time-based claims using a reliable clock, alongside signature, issuer, and audience or client checks appropriate to the token type. An application server whose clock is ahead can reject a still-valid token as expired. Time-based one-time passwords also depend on synchronized time. In AWS Directory Service environments, Kerberos authentication between domain members and domain controllers requires clocks to remain within the configured tolerance, commonly five minutes by default in Active Directory.

Troubleshooting starts by comparing the affected host's UTC time with a trusted reference and inspecting synchronization status. On Linux, chronyc tracking and chronyc sources can reveal synchronization failures and offsets; on Windows, w32tm can help inspect the time source and status. Check for blocked synchronization traffic, incorrect time sources, suspended virtual machines, and host clock problems. Containers generally share their host's clock, so the correction usually belongs on the host. A different displayed time zone is not itself skew if the underlying UTC instant is correct.

Correlate client errors, identity-provider logs, application token-validation failures, and available AWS CloudTrail events. CloudTrail provides service-side event timestamps and useful identity and error details, but not every rejected request produces an event, and event delivery time is not event occurrence time. Use request identifiers and inspect local timestamps rather than assuming all logs share an accurate clock.

Prevent recurrence with reliable time synchronization, offset monitoring, and checks after infrastructure changes. Increasing a configurable validation tolerance can accommodate small timing differences and transport delays, but accepting older timestamps increases the opportunity to reuse captured authentication material unless other replay controls prevent it. Fix synchronization rather than disabling expiration checks, extending credential lifetimes unnecessarily, or broadening IAM permissions. Use monotonic clocks for measuring elapsed durations inside applications; wall-clock corrections can otherwise distort timeout calculations.