The Wild West of Enterprise Logins
Picture the internet around 2001. For businesses, the web was a collection of digital islands. An employee at a large corporation might need to access a dozen different web applications for HR, sales, and travel, each requiring a separate username and password.
This wasn't just annoying; it was a security nightmare and an administrative headache. Prior to SAML, achieving any kind of single sign-on (SSO) was typically done with proprietary, vendor-specific solutions that didn't work with each other. If Company A wanted to give its employees secure access to a new web service from Company B, there was no standard way to make it happen. The problem was clear: companies needed a secure, universal language to let one system trust a user's identity vouched for by another system, all through a web browser.
Speaking the Language of the Era: XML
One of the most common complaints about SAML is its reliance on XML, a markup language that is famously wordy compared to the lightweight JSON used by today's APIs. But back in the early 2000s, XML wasn't just an option; it was the option for serious enterprise data exchange. The OASIS Security Services Technical Committee, formed in 2001, was explicitly chartered to create an "XML framework for exchanging authentication and authorization information." This choice was deliberate. XML was strongly typed, governed by strict schemas, and supported robust digital signatures—all critical features for building a secure and reliable system that enterprises could trust. The verbosity wasn't a bug; it was a feature that ensured machine-readability and strict validation, which were paramount for the corporate and government entities SAML was designed to serve.
The Breakthrough: Federated Identity
The true genius of SAML wasn't just its use of XML, but the model it standardized: federated identity. This introduced three key roles: the user (or principal), the Identity Provider (IdP), and the Service Provider (SP). The IdP is the system that knows and authenticates the user (like a company's internal login system). The SP is the application the user wants to access (like a cloud-based CRM). SAML defined a way for the IdP to pass a cryptographically signed document, called an assertion, to the SP. This assertion essentially says, "I have authenticated this user, and here are their details. You can trust me." This decoupled authentication from the application itself, creating a circle of trust that could extend across different organizations and security domains. This concept, which merged ideas from efforts like the Liberty Alliance's ID-FF and the Shibboleth project, became the foundation of modern enterprise SSO when SAML 2.0 was released in 2005.
Built for a Different Internet
SAML was designed for a browser-centric web. Its core flows involve redirecting the user's browser between the SP and the IdP to exchange information. This works beautifully for traditional web applications but explains why SAML can feel awkward for modern single-page applications (SPAs), mobile apps, and machine-to-machine communication. Protocols like OAuth 2.0 and OpenID Connect (OIDC) were created later to solve a different problem: delegated authorization for APIs. They are designed to let an application act on a user's behalf, which is a different use case than the enterprise SSO that SAML was built to master. While OIDC now also provides a modern authentication layer, it was born in a world of APIs and mobile phones—a world that didn't exist when SAML's architects were solving the most pressing identity problems of their time.
