An assumption baked into every expiring credential
Any authorization mechanism that depends on time — a token with an expiry, a time-limited grant, a scheduled access window — implicitly assumes that the system issuing it and the system checking it agree, at least closely enough, on what time it currently is. Clock skew, the difference between two systems' clocks, breaks this assumption in ways that run in both directions: a still-valid token can be wrongly rejected as expired, or a genuinely expired one can still be accepted because the verifying system's clock hasn't caught up.
Because time synchronization normally works quietly and reliably in the background, it's an easy dependency to overlook entirely when reasoning about why a time-based authorization check might occasionally behave inconsistently — the failure doesn't look like an authorization bug at first, it looks like unexplained flakiness.
Designing for tolerance rather than assuming perfection
Systems that depend on tight expiry windows need to explicitly build in a reasonable tolerance for clock skew, rather than assuming synchronization that, in any sufficiently large or distributed system, never holds perfectly across every component. This is a small, deliberate acknowledgment that a foundational, usually-invisible piece of infrastructure is itself a dependency the authorization design has to account for, not something safe to take entirely for granted.