CentralAuth uses two primitives for single sign-on: central login (Special:CentralLogin), which happens at the end of login/signup and copies the user's session from the local domain where they logged in to the central domain; and central autologin (Special:CentralAutoLogin), which happens when you first visit a wiki where you are not logged in, and it tries to copy the session from the central domain to the local domain (ie. log you in locally based on your previous central login). To a first approximation, central autologin uses subresource redirects which makes it unreliable (Safari and Firefox often block cookies during such redirects, Chrome might start doing so soon), while central login uses top-level redirects so it's fairly reliable (with the possible exception of Safari, no browser messes with cookies on top-level redirects today).
Except, the final step in central login is actually a subresource request to Special:CentralAutoLogin/refreshCookies, which for weird internal reasons is necessary to set the user tokens on the central login domain. If this request fails (and it probably does in Firefox etc), the central cookies will behave as if the "keep me logged in" checkbox ("remember me" session flag) hasn't been set - they will expire in 30 days instead of a year, and they will become invalid if the user doesn't make any request to the wiki farm for a 24 hour timespan (and so the central session expires in the session store).
This has been known for a while but we didn't really care. With the central session being more crucial for temp users, maybe we should. We could change the final step of central autologin to be two top-level redirects instead of one subresource request - that would make login and signup slower by a few hundred milliseconds, but it would also make the central session more reliable.