SAML in 2026: The Load-Bearing Wall

On a regular schedule, someone declares SAML dead and tells you to move everything to OIDC. Then you open an enterprise procurement questionnaire, find the SSO row, and read the word SAML in the requirements. The protocol people keep burying is the one their biggest customers demand.

Both sides are right about half of it. SAML carries the enterprise, and it stopped changing two decades ago.

The two flows share a skeleton

Put SAML and OIDC on the same track and they move in step for most of the trip. A user asks for a page they can't see yet, your app bounces them to an identity provider, the provider checks who they are once with whatever password-and-MFA it's set up to require, and your app gets a session and lets them in. Cover the labels and you'd struggle to tell the two apart.

They differ only in how the answer gets home; SAML keeps the whole exchange in the browser. The IdP signs an XML assertion, the browser auto-POSTs it to your ACS endpoint, and your app checks the signature, the audience, and the clock, all on one front-channel round trip.

OIDC splits that return in two. The provider hands the browser a short-lived code, your server takes the code and calls the token endpoint on its own connection, and back comes a signed JWT, straight from the provider with no browser in between. Add nonce and PKCE and you've closed most of the replay and interception gaps that SAML has to cover with strict XML validation.

On the diagram it narrows to one hop: * that server-to-server token call*. OIDC added it, SAML logs the same user in without it, and covers the interception risk that hop removes by validating signed XML instead.

Still runs the enterprise

SAML owns the installed base, and the installed base is enormous. Enterprise and government identity providers ship SAML 2.0 as a matter of course, and higher education and the public sector built their large federations on it. InCommon runs on SAML. Federal integrations run on SAML. When a customer's security team writes "must support SSO" on a questionnaire, they often mean "must support SAML," because their team configured the IdP for SAML years ago and the integration team has neither the time nor the authority to redo AD FS or an aging Okta tenant.

A B2B product that answers "we support OIDC" can lose that deal to a competitor that also ships SAML, and the loss has nothing to do with protocol quality.

By industry counts, roughly seventy percent of new SSO integrations built across 2025 and 2026 use OIDC, while SAML still holds the majority of live SSO configurations inside Fortune 1000 environments. Both facts stand. SAML keeps what exists, OIDC gets the new builds, and that split will persist for years.

One tax worth naming: vendors have long gated SAML behind enterprise pricing tiers, a practice sso.tax exists to catalog. If you are buying, expect the SAML line item to cost more. If you are selling, decide whether to charge for the one checkbox your enterprise buyers have no way around.

Frozen since 2005

SAML 2.0 became an OASIS standard in March 2005 and has not taken a major revision since. The committee kept publishing errata, and the errata fixed typos and clarified wording so two implementations would read the spec the same way. The maintainers classed those changes as non-substantive on purpose. The protocol you deploy today is the protocol from twenty-one years ago.

Compare the pace next door. OAuth 2.1 folded a decade of security lessons into the base spec, made PKCE mandatory, and killed the implicit flow. FAPI 2.0 hardened the stack for open banking. CIBA added a backchannel flow for devices without a browser. And in February 2026 the OpenID Foundation finalized OpenID Federation 1.0, which gives OIDC the automated trust propagation that big SAML federations like InCommon have relied on for years. That was the last capability SAML held over OIDC, and it is gone now.

One entry on this timeline belongs to SAML. Every entry after it shipped from the other side.

Frozen cuts both ways. A stable, well-studied protocol carries fewer surprises than a moving one, and security teams price that in. It also means the rough edges you hit today are the rough edges from ten years ago, because the committee stopped sanding them.

Where SAML sits in the stack

Most SAML confusion comes from stacking five separate jobs into one word. Split them apart:

• OAuth 2.0 handles authorization. It grants an app delegated access to a resource.
• OIDC handles authentication for modern surfaces. It rides on OAuth 2.0, carries identity in a signed JSON token, and fits web, mobile, SPA, and machine traffic.
• SAML handles authentication and federation for browser-based enterprise apps, carrying identity in a signed XML assertion.
• FIDO2, WebAuthn, and passkeys are the credential. They prove you are you at the identity provider, and they resist phishing because the key binds to the origin.
• SCIM handles the lifecycle. It creates the account before first login, updates it on a role change, and removes it when someone leaves.

Wire the jobs together and you get one flow, with SAML as one lane of it:

SAML covers two of those boxes, for one kind of application. It does nothing for your mobile client, your API, your provisioning, or your phishing resistance. That gap is what "just use SAML" and "just use OIDC" both miss.

Passkeys do not replace it

The common 2026 mistake is expecting passkeys to finish SAML off. The two operate at different layers, so neither can replace the other.

A passkey proves you are Jane at Jane's identity provider. SAML or OIDC then carries that proof to the app Jane opened. The passkey makes the login phishing-resistant, and the federation protocol makes it single sign-on. Stack them and you get phishing-resistant SSO, which is the thing most enterprise rollouts are chasing.

One login, both layers doing their jobs:

In practice the passkey lives at the IdP. Okta, Entra ID, and Ping register the credential and enforce the policy, then hand each app a SAML assertion or an OIDC token the same way they did before. The app does not touch WebAuthn. That separation lets an enterprise roll phishing-resistant login out to a hundred SaaS apps without changing a line in any of them, and NIST recognizing synced passkeys at AAL2 in SP 800-63-4 cleared the main compliance blocker. The protocol people call legacy now delivers your most modern credential.

The weak spots

SAML earned its reputation for sharp edges, and each edge traces back to its age.

XML comes first. SAML security rests on signing and canonicalizing XML, and XML signature wrapping has let attackers bypass authentication in library after library over the years. Researchers documented the attacks long ago and maintainers shipped the fixes, so the mitigation is boring and mandatory: keep your SAML library current, and validate signature, issuer, audience, and expiration before you create a session. Canonicalization also burns CPU, which is why SAML verification runs several times heavier than JWT verification under load.

Certificates come second. SAML trust rides on certificates both sides configure by hand, so a rotation means coordinated updates across the IdP and each relying party. Teams postpone the rotation because it hurts, and they stay exposed while they wait. OIDC sidesteps this. Providers publish keys at a discovery endpoint, and validation picks up new keys without a phone call.

Mobile comes third. SAML has no clean mobile binding, so mobile SAML depends on embedded WebViews, and Apple and Google have spent years pushing developers away from WebViews because they leak credentials and break the platform credential manager. For a mobile app in 2026, OIDC with the authorization code flow and PKCE is the path, and SAML is the workaround you accept when a customer forces it.

Enterprises push billions of SAML assertions a month without incident, which settles the fitness question. The trade is that you inherit twenty years of documented failure modes, and the spec will not evolve past them.

What to build

Working identity teams in 2026 mostly land on the same plan.

For anything new that you control, choose OIDC: smaller tokens, a real mobile and SPA story, discovery endpoints, active security work, and a clean path to passkeys.

For B2B software moving upmarket, ship both. Default to OIDC and add SAML before your first enterprise deal demands it, because that deal is coming. If running a SAML stack yourself sounds like a bad week, a provider that speaks both protocols buys you the coverage without the maintenance.

Three rules hold underneath either choice. Put passkeys at the IdP, so the login resists phishing no matter which protocol carries it. Keep authorization in the app, enforcing roles and permissions locally instead of trusting the assertion to do it. And wire up SCIM, because SSO without provisioning leaves you managing accounts by hand.

Where this goes

SAML is not leaving this decade. The installed base is too large, security reviewers treat it as a vetted control, and a better specification does not move an entrenched federation on its own. InCommon did not migrate when OpenID Federation shipped, and the AD FS estates will not either. A migration with no business case does not reach a roadmap.

The new work moved out, though. Passkeys, OAuth 2.1, FAPI, backchannel flows, federation tooling: the OpenID Foundation ships all of it, and the OASIS committee ships errata. SAML holds up the installed base while the crews frame new construction next door. It won the enterprise, then stopped building.

Support SAML because your customers run it. Build new on OIDC. Put passkeys under both, and let SCIM handle the comings and goings. That is enterprise authentication in 2026, and SAML is the load-bearing wall you are not allowed to remove.

Thanks

/J