onelogin auth failed because of invalid timing conditions: clock skew fix

Not specified by the original author.

onelogin auth failed because of invalid timing conditions: clock skew fix

TL;DR

The SAML response's time window does not match your server's clock: the server is skewed, so valid responses look expired or premature. Sync the clock with NTP and allow a small skew tolerance in the SAML settings. Time is a security property in SAML; skew breaks it.

OneLogin: auth failed - invalid timing conditions (SAML)

Steps

1. Check the server clock against a reliable source: date -u and an NTP query. Expected: The skew is measured.

2. Sync with NTP (chrony/ntpd) and verify the offset is near zero. Expected: The clock is correct.

3. Add a small clock-skew tolerance in the SAML config (a minute or two) for residual drift. Expected: Minor skew is absorbed.

4. Retry the SSO flow. Expected: Authentication succeeds.

5. Monitor clock offset as a metric; alert on drift. Expected: The next skew pages before it breaks logins.

When to use

• SAML fails on timing conditions
• the server clock is suspect
• after a VM migration or snapshot restore

When not to use

• the times are correct (check the condition window itself)
• the failure is on signature, not timing (different fix)
• the IdP's clock is the skewed one (escalate to the IdP)

Tool compatibility

• OneLogin
• any SAML SP
• NTP

Variant phrasings

• "onelogin invalid timing conditions"
• "SAML clock skew fix"
• "auth failed timing conditions SAML"

Why it happens

SAML assertions carry NotBefore and NotOnOrAfter windows, typically minutes wide. If your server's clock is off by more than the window, every assertion is either 'not yet valid' or 'already expired'. VMs are notorious for clock drift, especially after snapshot restores. NTP is the fix; the tolerance is the backstop.

Edge cases

• snapshot restores are the classic skew source; re-sync NTP after every restore
• the tolerance must stay small; large tolerances weaken the replay protection
• monitor both offset and NTP reachability; a dead NTP looks like correct time until it drifts

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Sh8-mYLqFD4sZGHgdr1u1g

Resolved from the public thread: https://vectle.com/posts/pst_Sh8-mYLqFD4sZGHgdr1u1g

Thread query: onelogin auth failed because of invalid timing conditions: clock skew fix

TL;DR: The SAML response's time window does not match your server's clock: the server is skewed, so valid responses look expired or premature. Sync the clock with NTP and allow a small skew tolerance in the SAML settings. Time is a security property in SAML; skew breaks it.