How to make a web based Single Sign On system not so 'single'

The university has a (web-based) single sign on (SSO) system with multi-factor authentication (MFA), and that MFA has recently become mandatory even for on-campus use. This change created a problem for a person here, where instead of being challenged for MFA once a day or so, they were challenged every time they needed to access a SSO-protected resource. Since this person did this a dozen or more times a day, they were kind of irritated about the situation. But this only happened for this one person, not for everyone else; they only got challenged roughly once a day, which was the rough intention of the SSO/MFA system.

Eventually the support people figured out what was going on. This particular person mostly works in their IMAP email client, and they go to SSO-protected websites only periodically, when they're dealing with email that requires it. They don't have any other regular use for a browser, so they don't normally have one running; instead, when they click on a link in their IMAP client (or manually open up the browser), they get a new session, and then when they're done they close the browser window and thus the entire browser session.

Unfortunately, the MFA challenge part of the university's SSO system uses (time limited) session cookies to remember that you've already authenticated with MFA. I can sort of see the logic, since session cookies are unlikely to be written to disk where another process on the same machine might make off with them, but it has the consequence that every browser session has to MFA separately. If you keep your browser running all day, you MFA once. If you shut your browser down once and restart it as part of applying updates, you MFA twice. And if you're like this person and close your browser after every time you use it, you get to MFA every single time you touch the 'Single Sign On' system. Everyone else who looked at this problem and tried to reproduce it keeps their browser running all of the time, so no one saw this issue.

One interesting thing about this issue to me is how it surfaces conflicting assumptions about how web browsers get used. For example, the people who designed the MFA flow assumed that session cookies were durable enough that they didn't need to mention on their web pages that if you closed your browser session, your MFA status would be forgotten. At the same time I do feel that regularly closing down your entire browser session is not a crazy thing, and there are probably other people out there who do it. Not everyone lives in their browser and keeps it running all of the time.

Another way to look at this issue is that it's an example of low level details leaking through into a high level, abstracted view of a SSO system. The high level view has nice diagrams of browser action flows and a mention of how your SSO authentication is remembered so you don't have to do it again, but the specific details of how that was implemented and how that interacts with concrete browser behavior show through in this case.

(The brute force solution adopted for this person was to have them keep a browser tab around all of the time. There really wasn't much other choice; the MFA vendor isn't going to change how their HTTP cookies work for one person.)

(This elaborates on a bit of a Fediverse conversation.)