Let’s imagine a hypothetical support ticket from a hypothetical customer. Their SAML based single-sign-on into an app isn’t working, and the error message says something about “session expired” - even though the session is brand new.
At this point, anyone shouting “their system clock is wrong” at the screen should e-mail me - I might have a job for you.
Hypothetically, what was interesting about this hypothetical case is that the hypothetical customer was using Azure AD as their SAML IdP. Nothing wrong with that, it’s popular and widely deployed. Somewhat to our surprise, though, two different hypothetical systems both had their system clocks wrong … yet only one exhibited the issue.
We eventually pinned it down: the problem applied to the system where the clock was wrong backwards, but not the one where it was wrong forwards. Yes, it seems this particular integration of Azure AD was perfectly happy to receive SAML assertions made 15 minutes in the past … but not the future. Odd, eh?
Well, it would be if it had actually happened.
Update a colleague who is better than me at working Google notes that SAML specifies a start and end time for the validity of its assertions (in contrast to OAuth2 where I believe it’s just a single timestamp for expiry). That goes some way towards explaining how the problem could have arisen.