"What have we done to ourselves? I'm tired of having to log into so many apps. I'm logged in the second I walk into the office after scanning my badge at the door!"
That's a fair complaint, and it's worth taking seriously instead of waving off as a person just being tired on a Tuesday. The feeling is accurate. A badge tap is instant, all day, at every door. An inbox full of separate app logins is not. The interesting question isn't whether that's annoying — it obviously is — it's why the two ever ended up so far apart in the first place, because it isn't laziness on anyone's part. It's a structural difference between what a badge has to trust and what an app has to trust.
A building's badge system works because there's exactly one authority in play. One vendor's reader, one vendor's door controller, one access-control database, all bought by the same facilities team, all agreeing on what a valid badge looks like before any of it got installed. The badge reader at the parking garage and the one outside the server room are checking the same credential against the same source of truth. There was never a second company's login screen standing between you and the next door.
Software apps aren't built that way, almost none of them. Each one is its own separate business, running its own separate identity system, with its own idea of what a valid session looks like. Getting from "logged into the badge system" to "logged into everything" doesn't mean flipping one switch — it means someone has to go build a trust relationship with each of those separate kingdoms, one at a time. That's exactly the shape of the federation problem MCP's Enterprise-Managed Authorization is trying to solve for AI tools: one sign-in, forwarded to every tool that's agreed to accept it — except it only works for the tools that built the bridge, and plenty haven't.
Even where single sign-on genuinely is wired up, a lot of apps still ask more often than a badge does. Part of that is a real, defensible choice: a shorter session on something sensitive means a stolen token is only useful for a narrow window, the same reasoning behind keeping any credential's blast radius small on purpose. A badge that worked for a week straight after one tap would be a worse building, not a better one.
But not every short session in a workday is a decision someone actually made. A lot of them are just whatever a vendor shipped as the default, copied into a config and never revisited, the same way an unexamined default quietly becomes the shape of a system nobody chose on purpose. "This app logs you out every four hours" and "we decided this app should log you out every four hours" are different sentences, and most companies can't actually tell you which one is true for most of the apps they run.
A share of that daily pile is the hard 20% that doesn't speak the protocol yet — older systems, or ones whose vendor never built the federation bridge, sitting there needing their own login indefinitely because nobody's going to rebuild them just to fix a sign-in flow. That's a real, honest constraint, not an excuse. Naming it plainly is more useful than pretending every app is one integration away from disappearing into a single sign-on.
The complaint isn't really about any one app. It's that nobody at most companies can answer, off the top of their head, exactly how many separate logins a new employee ends up with, or why each one still requires its own. The same gap that lets a vendor migration quietly drop notifications nobody assigned an owner to is the gap here — not a missing piece of technology, a missing line item nobody's job description includes. Somebody owning that list, the way somebody owns a budget, would turn "what have we done to ourselves" from a shrug into an actual answer: here's the list, here's which ones are federated, here's which ones are the hard 20%, and here's who's responsible for shrinking it.
Field Mappings