The History and Future of SAML: Why a 20-Year-Old Protocol Still Matters

Protocols don't die; they accumulate gravity. Every integration, every compliance mandate, every federated trust relationship adds mass. SAML has been accumulating gravity for over twenty years, anchoring identity federation across enterprises, governments, universities, and healthcare systems worldwide. Dismissing it as "legacy" is a misreading of how protocol ecosystems actually work. SAML isn't fading. It's entrenched. Understanding why it endures is essential for anyone building identity infrastructure that operates in the real world.

This post traces SAML from its origins in the early 2000s through its current role in the identity landscape, and looks ahead to where the protocol is going — not as a replacement story, but as a coexistence story.

The Origins: SAML 1.0 to SAML 2.0

In the early 2000s, organizations faced a deceptively simple problem: how do you let a user authenticated in one domain access resources in another, using nothing but a web browser? The answer was fragmented and proprietary. Netegrity SiteMinder, IBM Tivoli Access Manager, and Oblix NetPoint each solved pieces of the puzzle but locked customers into vendor ecosystems. The web was growing, enterprises were connecting, and no open standard existed for exchanging authentication and authorization data between organizations.

The OASIS Security Services Technical Committee (SSTC) convened in January 2001, chaired by Eve Maler of Sun Microsystems, with a charter to "define an XML framework for exchanging authentication and authorization information." Several competing proposals were contributed: Netegrity's S2ML, Securant's AuthXML, VeriSign's X-TASS, and Jamcracker's ITML. These contributions were the raw material from which SAML was forged.

SAML 1.0 was ratified as an OASIS Standard in November 2002, defining the core assertion model and the browser/artifact and browser/POST profiles. Adoption was limited; the specification was complex, and the profile definitions were incomplete. SAML 1.1 followed in September 2003, a modest refinement that stabilized the foundation but still lacked a unified Web SSO profile.

Meanwhile, two other efforts converged on the same problem space. The Liberty Alliance Project, founded in September 2001 by Sun Microsystems and more than 150 member organizations, developed the Identity Federation Framework (ID-FF), which introduced the concept of a "circle of trust" for organizations sharing identity assertions. Liberty contributed ID-FF 1.2 to OASIS in November 2003. Shibboleth, an Internet2 project focused on academic federation, brought deep experience in cross-institutional identity for higher education and research.

SAML 2.0 was ratified as an OASIS Standard in March 2005, merging SAML 1.1, Liberty Alliance ID-FF 1.2, and Shibboleth's contributions into a single comprehensive specification. It defined the Web Browser SSO Profile, introduced metadata exchange for automated trust establishment, and standardized protocols for Single Logout, Name Identifier Management, and Artifact Resolution. The OASIS ratification provided neutral, vendor-independent governance that enterprises, governments, and universities needed to trust the specification.

Timeline:

Why SAML Won Enterprise SSO

SAML 2.0 arrived at exactly the right moment. XML was the lingua franca of enterprise integration (SOAP, WS-Security, XML Schema), and SAML fit naturally into existing middleware. Its browser-based POST-and-Redirect bindings worked in every web browser without JavaScript or plugins. The metadata model enabled automated trust establishment at scale, replacing manual configuration exchange.

Enterprise vendor adoption was rapid and deep. Microsoft shipped SAML 2.0 support in Active Directory Federation Services (ADFS). Oracle, IBM, CA Technologies, and Sun built it into their identity products. Salesforce, Google Apps, Box, and dozens of SaaS platforms added SAML Service Provider support. Each integration created a network effect: the more systems that spoke SAML, the harder it became to justify an alternative.

SAML solved the 80% case (browser-based SSO between organizations) well enough that there was no pressure to replace it. And certification programs cemented the lock-in: FedRAMP, FICAM, and the InCommon Federation all standardized on SAML. Once compliance frameworks require a specific protocol, switching costs become regulatory costs — orders of magnitude more expensive than technical migration alone.

The OIDC Era: What Changed and What Didn't Replace SAML

OpenID Connect Core 1.0 was ratified in February 2014 and is built on OAuth 2.0 for use across mobile apps, REST APIs, SPAs, and JSON-native systems. OIDC solved real problems that SAML didn't: native mobile authentication via OAuth 2.0's authorization code flow with PKCE, API authorization through access tokens and scopes, dramatically better developer experience (JSON, JWTs, discovery endpoints), and dynamic client registration. For mobile apps, SPAs, and API-driven architectures, OIDC was genuinely better.

But OIDC did not replace SAML. Existing federation agreements, complete with legal frameworks, metadata exchange, and operational playbooks, don't rewrite themselves because a new specification exists. Entire federation networks run on SAML: InCommon connects over 1,000 organizations, and eduGAIN connects over 80 national federations with more than 10,000 providers serving nearly 27 million users. Government compliance mandates (NIST SP 800-63C, Login.gov, FedRAMP) explicitly reference SAML. Every major enterprise IdP (Entra ID, Okta, Ping Identity, OneLogin, JumpCloud, Google Cloud Identity) supports SAML as a first-class protocol.

The coexistence pattern emerged naturally. New applications used OIDC. Existing integrations stayed on SAML. Identity providers evolved to speak both. This is the steady state, not a transitional one.

Advising organizations to "just migrate to OIDC" ignores concrete realities: every Service Provider must be reconfigured, every trust relationship re-established, some partners only speak SAML and won't change for you, and replacing a working system introduces new failure modes without eliminating risk.

Where SAML Persists and Why

SAML is dominant in sectors that represent enormous economic and institutional weight.

Enterprise SSO remains the backbone of corporate identity federation. Workday, Salesforce, ServiceNow, SAP SuccessFactors, HubSpot, and dozens of other platforms support SAML, and many enterprise customers require it. The SCIM-for-provisioning, SAML-for-authentication pairing is deeply established in enterprise IT operations.

The U.S. Federal Government runs critical identity infrastructure on SAML. FedRAMP authorization, Login.gov, NIST SP 800-63C, and the FICAM architecture all reference or require SAML-based federation. When federal standards require SAML, every vendor in the federal supply chain must support it, driving adoption across the entire public sector.

Healthcare depends on SAML for organizational-level identity federation under HIPAA's strict privacy requirements. Health Information Exchanges like Carequality and the eHealth Exchange use SAML for cross-organizational trust, while SMART on FHIR uses OAuth 2.0/OIDC for app-level API access. The two protocols coexist naturally.

Higher Education is SAML's deepest stronghold. InCommon connects over 1,000 U.S. organizations through SAML-based federation, providing access to over 6,000 services. eduGAIN connects over 80 national federations globally. A researcher at MIT can access a computing cluster in Munich using their home university credentials via SAML and the eduGAIN trust chain. Shibboleth remains the dominant identity platform in higher education.

These sectors change slowly, not because they're backward, but because federation is a multi-party agreement. You can't unilaterally switch protocols when InCommon has a thousand members, and eduGAIN has ten thousand providers. Migration requires coordinated action across hundreds of organizations, each with its own governance, budgets, and risk tolerance.

The Future: SAML Isn't Being Replaced, It's Being Complemented

The dual-protocol identity provider is the new normal. Organizations need OIDC for mobile apps, SPAs, and APIs. They need SAML for enterprise partners, government integrations, and academic federations. The identity provider that speaks both protocols from a single platform eliminates the false choice.

The core specification is stable: the OASIS SSTC completed its work and was formally closed in July 2023, a signal of maturity rather than abandonment. The ecosystem continues to develop through better metadata management, protocol bridging with OIDC, improved tooling, and community-driven security guidance.

Future architectures will increasingly treat protocols as transport layers. The identity provider becomes a protocol translator, accepting SAML from an enterprise partner, issuing OIDC tokens to a mobile application, and maintaining a unified session across both. The protocol becomes an implementation detail, invisible to consuming applications.

Predictions for the next decade: SAML usage will plateau but not decline meaningfully. The coordination cost of migrating federation networks with thousands of members is simply too high to justify when the protocol works. Existing federation networks (InCommon, eduGAIN, government federations) will remain SAML-based for the foreseeable future. The biggest growth area will be in emerging markets adopting e-government identity frameworks, where SAML's mature trust model provides a proven foundation. AI and automation will reduce SAML's operational burden by automating metadata management, monitoring certificate rotations, and validating configurations.

For teams building identity infrastructure that serves enterprise partners, government agencies, and academic institutions, dual-protocol support is not optional. It's a practical requirement driven by the federation landscape described above.

What This Means for Duende and IdentityServer v8

IdentityServer v8 adds first-class SAML 2.0 support, recognizing that the market demands both protocols from a single identity solution. You can't serve enterprise, government, healthcare, or education customers without SAML.

What IdentityServer v8 SAML support includes:

• SAML 2.0 Identity Provider capabilities (issue assertions to registered Service Providers)
• Metadata generation and consumption for automated trust establishment
• Certificate management for signing and encryption
• Attribute mapping and claim transformation between SAML attributes and OIDC claims
• Support for SP-initiated and IdP-initiated SSO
• Single Logout across protocol boundaries

The dual-protocol architecture means a single IdentityServer v8 instance serves both worlds. A user authenticates once, and the session is protocol-agnostic. The same instance can issue OIDC tokens to your SPA and SAML assertions to your enterprise partner, with logout propagating across both protocols and claims normalized internally.

Conclusion

SAML's longevity reflects real, ongoing needs in sectors that handle trillions of dollars in economic activity and operate under the strictest security and compliance requirements on the planet. They chose SAML because it solved their problems. They keep it because the cost of switching exceeds the benefit.

The "SAML vs. OIDC" framing is false. The real question is: "How do I serve both?" OIDC for mobile apps, APIs, and consumer-facing applications. SAML for enterprise federation, government compliance, and academic research networks. Both, simultaneously, from a single solution.

IdentityServer v8's SAML support is Duende's answer to that question.

Sources and Further Reading

1. OASIS Security Services (SAML) Technical Committee
2. OASIS SAML 2.0 Specification (Ratified March 2005)
3. SAML Technical Overview (OASIS Committee Draft)
4. InCommon Federation (Internet2)
5. eduGAIN Interfederation Service (GÉANT)
6. NIST SP 800-63C: Federation and Assertions
7. OpenID Connect Core 1.0 Specification
8. FedRAMP Authorization Requirements
9. Login.gov SAML Integration Documentation
10. Federal Identity, Credential, and Access Management (FICAM)
11. REFEDS (Research and Education Federations)
12. Liberty Alliance Project (Historical, succeeded by Kantara Initiative)
13. Duende IdentityServer Documentation