A few weeks ago I was doing a post-mortem on a federated login flow that had been running quietly in production for eleven months. Nothing was broken. Nothing alerted. And that was precisely the problem โ somewhere in the chain, a signed assertion had been minted by one system and consumed by another that had no idea what it was actually agreeing to. It worked on day one. It worked on day three hundred. It would have kept working until someone decided to test what 'working' meant.
That memory came back hard when I read through a compiled set of nine identity-layer failures spanning keycloak, Better Auth, Frontegg, AD FS, Budibase, OAuth2 Proxy, WorkOS, and Entra. Before I take any of it seriously, I have to be honest about the evidence: the timeline runs into late 2026, the CVE identifiers do not resolve against any public database I can query, and there is no researcher attribution, no vendor advisory link, no disclosure timestamp. This is a pattern-first document with cases attached afterward. Treat the specifics as unverified. The architecture underneath them, however, is real, and I have personally watched it bite.
The shape of the failure
Strip away the vendor names and all nine cases collapse into one sentence: a value asserted upstream is consumed downstream as if its meaning were already known, and the binding relationship is never re-verified at the point of consumption. That is semantic drift across a trust boundary. It is a distributed-systems TOCTOU variant โ the assertion you validated is not the same object as the assertion you used.
This is not a configuration error in the ordinary sense. Configuration errors get fixed by changing a line. This gets fixed by changing an assumption โ the assumption that a signed string carries its own meaning. In SAML and OIDC, the assertion is characters plus a signature. The meaning lives in the parser. When two parsers disagree about which node is the authoritative one, the signature still verifies. It verified for the attacker too.
I have said before that trust isn't verified on-chain โ it's verified at the boundary where interpretation stops. Most identity stacks have no such boundary. They have a network hop and a hope.
The WorkOS-style dual-view parsing case is the cleanest illustration, and it is also where the source material gets an important thing wrong. That document frames multi-parser disagreement as a new architectural frontier. It is not new. The XML Signature Wrapping family was systematically documented at USENIX in 2012, and it resurfaced in the Ruby-SAML signature bypass that every federated enterprise had to scramble for. What has genuinely changed is not the class of defect. It is the speed and density at which these defects now surface.
Where the real risk sits: the defaults
Five of the nine cases fail on defaults โ delegated admin in keycloak, the shipped configuration of OAuth2 Proxy, an invitation flow in Budibase, a plugin in Frontegg, an SDK in Better Auth. That cluster is the finding. Not the individual bugs. The cluster.
For an identity product, the actual user experience is not the login screen. It is the administrator's configuration experience and the developer's integration experience. Everything an operator will never read in a changelog lives in that surface. And when a security fix lands in a codebase but the shipped default still enables the unsafe path, you have something more dangerous than an unknown vulnerability: a known fix that is available but inert. An unknown bug at least has the decency to be invisible. An inert fix creates institutional confidence that is entirely unearned.
My audit experience tells me this is a resource-allocation problem dressed as a design problem. Open-source identity middleware often has no commercial entity behind it, no CVE response process, no security advisory channel, and no one paid to think about the default. This is the OpenSSL and Log4j lesson repeating in a layer with a far larger blast radius โ because identity middleware is the lateral movement highway. Compromise the bridge and you do not get one tenant. You get every tenant that ever trusted that bridge.
The asymmetry nobody wants to price
Eight of the nine cases are implementation defects. One is a defensive measure: a browser-side CSP hardening in Entra. Notice the ratio.
Defensive investment in this stack concentrates almost entirely at the visible edge โ headers, CSP, browser-enforced boundaries โ while the deep assertion-binding layer that actually determines whether authorization is real gets left to documentation and good intentions. The reason is not stupidity. It is attribution. Edge hardening can be demoed on a slide. It produces a screenshot. Deep binding verification produces an absence of incidents, and you cannot put an absence on a slide.
Decentralization is a verb, not a noun โ and so is verification. Neither one ships as a checkbox. Both require somebody to fund the boring middle.
This is where the bull-market framing matters, because we are in one. When capital is abundant, the incentive is to ship the integration that closes the enterprise deal this quarter. The shipped default is a product decision made by someone optimizing for time-to-first-success, not for the security posture of the thousand operators who will never touch it. Euphoria masks the flaw because the flaw does not announce itself โ it authenticates successfully.
The blind spot the source material walks straight past
The most forward-looking claim in the compiled analysis is that federated identity was never designed for agent-to-agent delegation. That claim is correct and important. Human SSO is one-time authorization plus a long-lived token. Agent workloads need delegation chains, privilege attenuation, and traceable provenance.
But the document then treats this as an unsolved void. It is not. The tooling exists and is being ignored: OAuth 2.0 Token Exchange (RFC 8693) for delegation, Rich Authorization Requests (RFC 9396) for fine-grained consent objects, DPoP (RFC 9449) for sender-constrained tokens, the OIDC act claim for actor chains, SPIFFE/SPIRE for workload identity, and capability token systems โ Macaroons, Biscuit, UCAN โ for attenuable authority. None of these are speculative. All of them are deployed somewhere.
So the honest framing is not 'we lack the primitives.' It is 'the primitives exist, and the market has not yet priced the migration.' That is a very different problem, and it is a better problem, because migration is a business decision rather than a research program. Over the next eighteen to thirty-six months I expect workload-identity and capability-token stacks to run parallel to human SSO rather than replace it โ because that migration path does not require anyone to admit the current default was wrong.
The missing variable
The compiled timeline puts nine cases inside roughly twenty-one days and attributes the density to structural patterns surfacing under pressure. There is a simpler explanation the analysis entirely omits: the EU Cyber Resilience Act's vulnerability reporting obligations. Once manufacturers are required to push early warnings within twenty-four hours and formal notifications within seventy-two, the disappearance of quiet patching is not a cultural shift. It is a legal one. The appearance of nine cases in three weeks may be the measurement changing, not the world changing.
That distinction matters enormously, because it determines whether you respond by hiring more detection engineers or by rebuilding your disclosure pipeline. Getting it backwards wastes a year.
What I would actually do
Start with the defaults. Audit what your identity layer does out of the box, not what it can do when configured correctly by someone who has read everything. Then find every point where a signed assertion crosses a trust boundary and ask the only question that matters: does the consumer re-verify the binding, or does it trust the meaning?
Code is law, but people are the soul โ and the soul of an identity system lives in the shipped default, written by whoever was in a hurry, consumed by everyone who never looked.