SAML 2.0 — How the Federated Single Sign-On Standard Works

What is SAML 2.0?

Security Assertion Markup Language version 2.0 is an open standard for exchanging authentication and authorization data between two independent parties: an identity provider and a service provider. It was ratified by OASIS in March 2005 and remains one of the pillars of enterprise single sign-on (SSO).

A common misconception is worth clearing up immediately. SAML is not a model, a library or a product — it is an integration standard, a set of formal specifications describing what an authentication message should look like, how to sign it and how to transport it across the network. It is also not the same thing as OAuth or a password. Its sole job is to let a target application trust the statement "this user has been correctly verified", issued by another trusted party, without ever sharing the password.

The problem SAML solves is password fatigue and the need for single sign-on across multiple domains at once. Classic cookie-based mechanisms worked only within a single domain and a single server. The rise of cloud services and B2B^?B2B: Business-to-Business — a model where the customer is another company rather than an individual consumer. In an SSO context it refers to exchanging identity credentials between independent organisations. software forced the creation of a universal way to carry identity between completely independent systems. In a federated model the target service never sees the user's password — it relies solely on a cryptographic confirmation issued by a trusted third party.

Who is behind it?

SAML 2.0 did not emerge from one place — it is a fusion of three independent streams. The first was OASIS, which set up the SSTC technical committee in January 2001 and produced SAML 1.0 (November 2002) and SAML 1.1 (September 2003). These early versions were conceptually important but lacked a unified web login profile, and the flow almost always had to be initiated on the identity provider side.

The second stream was the Liberty Alliance, a consortium founded in September 2001 by Sun Microsystems together with more than 150 partners. It produced the Identity Federation Framework (ID-FF) and introduced the "circle of trust" concept — a structure that lets federated organizations share authentication credentials. The third was the academic Shibboleth project, coordinated by the Internet2 network, which added a simple HTTP-based request protocol and reversed the login flow, enabling a scenario initiated by the target application.

In November 2003 the Liberty Alliance contributed ID-FF 1.2 to OASIS, and the Shibboleth researchers handed their work to the same committee. The result of this unification was SAML 2.0, which merged SAML 1.1, ID-FF 1.2 and Shibboleth 1.3 into a single specification. Backing from major vendors, notably Microsoft, which implemented the standard as Active Directory Federation Services^?Active Directory Federation Services: A Microsoft service (AD FS) that acts as a SAML identity provider — it authenticates users against Active Directory and issues signed assertions to applications., cemented its dominance in the enterprise segment.

How does it work?

The most common use of the standard is the Web Browser SSO profile, in which the browser acts as an intermediary carrying messages between the parties. The Service Provider-initiated flow is considered the most secure operational variant and works as follows.

The login flow step by step (SP-Initiated)

1. A user visits a protected application, for example Salesforce. The application does not recognise an active session.
2. The application generates an AuthnRequest XML document, encodes it and sends the browser an HTTP 302 redirect.
3. The browser carries the request to the identity provider's sign-in endpoint. If the user already has an active global session, the credential step is skipped — otherwise a login screen appears (Active Directory, multi-factor authentication or biometrics).
4. After successful verification the identity provider builds a SAML assertion, signs it with its private key and wraps it in a Response message.
5. The assertion returns via HTTP POST: the identity provider generates an HTML page with a hidden field containing the encoded response and a small piece of JavaScript that automatically submits the form to a receiving endpoint on the application (service provider) side, called the Assertion Consumer Service (ACS).
6. The application parses the document, verifies the digital signature using a known public key, checks conditions (audience restriction and validity window) and establishes a local session.

There is also an IdP-initiated variant, where the user starts from a corporate application dashboard. It is rarer and more exposed to RelayState parameter abuse.

What are its key components?

SAML's architecture is highly modular and rests on four foundations.

• Assertions — signed XML documents issued by the identity provider. They split into authentication statements (confirming when and how the user logged in), attribute statements (carrying metadata such as role, department or email) and the less common authorization decision statements.
• Protocols — define the request and response format. The most important is the Authentication Request Protocol describing the AuthnRequest and Response exchange.
• Bindings — specify how a message travels across the transport layer: HTTP Redirect for short requests, HTTP POST for bulky assertions and HTTP Artifact, in which the browser carries only a short token while the actual assertion is fetched over a back channel.
• Profiles — combine these elements into ready business scenarios, with the Web Browser SSO profile leading the way.

Two further elements hold everything together.

• Metadata — XML files describing each party's technical capabilities: a unique Entity ID, endpoint addresses and X.509 certificates that let the recipient verify signatures.
• XML Signature — a W3C standard protecting message integrity. The signature can cover the whole response or just the assertion, uses references by identifier and relies on a canonicalization algorithm (c14n) that normalizes the tag structure regardless of whitespace.

What can it be used for?

SAML's primary domain is enterprise SSO^?SSO: Single Sign-On — one authentication grants access to many independent applications without re-entering a password. in B2E^?B2E: Business-to-Employee — a model where the service is delivered to an organisation's own employees. and B2B^?B2B: Business-to-Business — a model where the customer is another company rather than an individual consumer. In an SSO context it refers to exchanging identity credentials between independent organisations. models. An organization rolling out dozens of cloud applications for employees uses an identity platform — Microsoft Entra ID, Okta, OneLogin or Ping Identity — to log the team into Salesforce, Slack, Workday or Box through a single mechanism, without duplicating password management. For a modern SaaS^?SaaS: Software as a Service — software delivered as a cloud service, accessed through a browser and billed by subscription. vendor, SAML support is often a precondition for signing an enterprise contract.

The second major area is academic and government federations. Because of its kinship with Shibboleth, SAML underpins a large share of the world's research federations, such as the American InCommon or the pan-European eduGAIN, as well as public-sector deployments under regulations like Login.gov or eIDAS. One boundary is worth remembering: SAML does not manage accounts or provisioning — creating and deactivating accounts uses a separate standard, SCIM^?SCIM: System for Cross-domain Identity Management — a standard that automates creating, updating and deleting user accounts across systems (provisioning). It runs alongside SAML, which handles login itself., which runs alongside SAML.

How does it differ from other approaches?

OAuth 2.0

The most frequent conceptual error is confusing SAML with OAuth 2.0. OAuth is not an authentication protocol — it is a framework for delegated authorization that lets an application access an API on the user's behalf using an access token, without sharing a password. The difference is captured most simply by two questions:

• SAML answers "who are you".
• OAuth answers "what are you allowed to do".

OpenID Connect

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It adds an ID Token in JSON Web Token format and is far lighter than XML assertions, which makes it a better fit for mobile, native and single-page applications. OIDC is often called the successor to SAML and genuinely wins in the consumer and API-first world.

In practice SAML remains the choice for complex enterprise environments, and OIDC for new web and mobile applications.

WS-Federation

WS-Federation is an older standard from the Microsoft and IBM WS-* family, functionally close to SAML but gradually displaced by it.

Differences between OAuth 2.0 and SAML 2.0

Although the two standards are often mentioned in the same breath, they solve two different problems. Confusing them is the most common conceptual error in the identity space — and in practice it leads to real security gaps. SAML 2.0 was created to answer the question of identity. OAuth 2.0 was created to answer the question of access.

Authentication versus authorization

SAML 2.0 is an authentication protocol. Its job is to confirm to an application that "this user is who they claim to be and has just logged in". The identity provider verifies the credentials and issues a signed assertion describing who the user is and what attributes they hold.

OAuth 2.0, by contrast, is an authorization framework — and crucially, it is not an authentication protocol. Its job is to let an application access a resource on the user’s behalf without ever handling their password. The classic analogy is the "valet key": you hand over limited access, not full control. OAuth says nothing reliable about who the user is — it only states that an application has been granted permission to perform specific operations.

This distinction has a serious consequence. Using OAuth 2.0 alone as a login mechanism ("sign in with…") is a historical source of vulnerabilities — an access token was never designed to assert identity. That is exactly why OpenID Connect exists: it adds a standardised identity layer (the ID Token) on top of OAuth 2.0. SAML fills that role natively, without any add-on.

Format, flow and carrier

SAML operates on bulky, signed XML documents transported through the browser via redirects and auto-submitted POST forms. It is a model designed for a human with a browser in an enterprise environment. OAuth uses lightweight access tokens (often opaque or in JWT format) exchanged directly between the application and the authorization server through API calls. This is why OAuth scales far better to mobile, native and machine-to-machine scenarios, where heavy XML and a browser-mediated flow would be an obstacle.

When to use which

The practical rule is simple. When the goal is single sign-on for an employee into a corporate web application, SAML is the natural choice — it is its core use case and a requirement of most enterprise platforms. When the goal is to grant an application limited access to a user’s data or API without revealing a password, OAuth is the right tool. When modern authentication for a mobile or SPA application is needed, you reach for OpenID Connect — that is, OAuth 2.0 with an identity layer added. In practice the two worlds frequently coexist: SAML governs who enters the application, while OAuth governs what the integrations connected to it may do with the user’s data.

Key limitations and challenges

The SAML specification itself has been repeatedly validated, and vulnerabilities arise mainly at the implementation layer. XML is hard to parse and burdened by historical baggage, which leads to bugs in libraries.

XML Signature Wrapping

The most important class of attacks is XML Signature Wrapping (XSW). An attacker intercepts a legitimately signed assertion, moves the original element lower in the XML tree and injects a forged fragment with elevated privileges. The problem stems from a logic mismatch: one module verifies the signature on the original element and deems the document safe, while another reads identity data from the forged fragment. A related threat is XML External Entity (XXE), exploiting careless parsers that accept malicious DTD definitions.

Golden SAML

The most dangerous, however, is Golden SAML, described by CyberArk researchers in 2017. An attacker who gains administrative access to the identity provider (typically an AD FS server) steals the token-signing key. From that moment they can generate arbitrary, perfectly signed assertions, impersonate any user and declare a successful multi-factor authentication, neutralizing it entirely. This vector played a key role in the SolarWinds^?SolarWinds: A US IT company whose Orion software became the vector of a major 2020 supply-chain attack affecting US government agencies and thousands of organisations. supply-chain breach uncovered in late 2020. The Silver SAML^?Silver SAML: A variant of the Golden SAML attack described by Semperis in 2024 that moves the assertion-forging mechanism into cloud-based Microsoft Entra ID. variant, described by Semperis^?Semperis: An identity-security company (focused on protecting Active Directory and Entra ID) that documented the Silver SAML attack. in 2024, carries a similar mechanism into cloud-based Microsoft Entra ID environments by abusing the import of externally generated signing certificates.

SAML as the gateway to enterprise AI tools

One of the less obvious roles of SAML in 2024 is that it has become the infrastructure conditioning the pace of AI tool adoption inside organisations. Every serious enterprise-grade AI product lists a correctly configured SSO integration as a contractual requirement — and in the vast majority of cases that means SAML.

ChatGPT Enterprise, GitHub Copilot, Microsoft 365 Copilot, Salesforce Einstein, Google Workspace AI, Workday AI, ServiceNow — each of these deployments requires the corporate customer to have a working SAML 2.0-compliant identity provider. The reason is pragmatic: without centralised access control an organisation cannot guarantee that only authorised employees reach the AI tool, nor that an employee departure automatically revokes access.

This means organisations that have not yet deployed SAML hit an AI adoption bottleneck before they can even evaluate the model — they must fix their identity infrastructure first. Conversely, companies with a mature SAML layer (Okta, Microsoft Entra ID as IdP, AD FS) can connect a new AI tool in a matter of hours by configuring a single service provider integration. SAML has become the de facto pass that enables AI tools to scale across the enterprise.

A new risk vector also emerges: the more AI applications are connected to a single IdP via SAML, the more attractive that identity provider becomes as a target. A Golden SAML attack on an IdP that simultaneously controls access to ChatGPT Enterprise, GitHub Copilot and the HR platform gives an attacker access to sensitive data on an unusually wide front.

AI agents and the limits of SAML

SAML rests on one fundamental assumption: a human with a browser is on the other side of the message. AI agents do not meet that assumption — and this is a structural boundary, not a missing feature.

The Web Browser SSO profile^?Web Browser SSO: The most common SAML profile — it describes the single sign-on flow in which messages travel between parties through the user's browser. requires a user-agent^?user-agent: The client-side program that communicates with servers — in practice a web browser. that can send an HTTP request, process an HTTP 302 redirect, render a login form and submit the resulting POST to the Assertion Consumer Service^?Assertion Consumer Service: The endpoint on the application (service provider) side that receives and processes the SAML response carrying the assertion.. A programmatically operating agent — an LLM orchestrator, a RAG pipeline, an RPA automation script — does not have these capabilities. It can simulate a headless browser, but that is a workaround prone to errors and unacceptable in a production environment with security rigour.

How machine identity is handled

For machine-to-machine (M2M) communication the industry has settled on different tools. OAuth 2.0 Client Credentials Flow issues a token to an application (not a person) with no user interaction. OIDC Workload Identity — in implementations such as Microsoft Entra Workload Identities^?Microsoft Entra Workload Identities: A Microsoft Entra mechanism that assigns identity to applications and services (workloads) rather than people — for machine-to-machine authentication. or Google Workload Identity Federation^?Google Workload Identity Federation: A Google Cloud service that lets workloads outside GCP authenticate without long-lived service keys, based on an external identity provider. — assigns a cryptographic identity to a workload running in the cloud. SPIFFE/SPIRE^?SPIFFE/SPIRE: An open standard (SPIFFE) and its implementation (SPIRE) that give services a cryptographic identity in cloud-native environments, independent of static secrets. delivers SVID certificates^?SVID: SPIFFE Verifiable Identity Document — an identity document (typically an X.509 certificate or JWT) issued to a service in the SPIFFE model. to services in cloud-native environments, decoupling identity from static secret keys.

SAML has no equivalent of any of these mechanisms for programmatic clients. A SAML assertion is not bound to a key by a Proof of Possession mechanism, meaning that an intercepted SAML token can be replayed — in contrast to OAuth 2.0 tokens using DPoP^?DPoP: Demonstrating Proof of Possession — an OAuth 2.0 mechanism that cryptographically binds a token to the client's key, so a stolen token cannot be replayed. (Demonstrating Proof of Possession), which are cryptographically bound to a specific client key.

Delegation and the agentic AI problem

The hardest scenario is an agent acting on behalf of a user: sending emails in their name, reading documents from SharePoint, filling in forms in ERP^?ERP: Enterprise Resource Planning — an integrated system for managing a company’s core processes (finance, HR, inventory, production). systems. The user authenticated via SAML, but the agent needs a token with a scoped set of permissions — and the SAML architecture has no ready answer here.

In practice this is resolved through a hybrid: the user logs in through SAML SSO and the platform (for example Microsoft Entra) issues an OAuth token with precisely defined scopes in the background, which is then passed to the agent. The agent never sees the SAML credentials — it operates solely on a short-lived OAuth token with limited scope. This is a responsible architecture, but it requires deliberate design, and most legacy SAML systems do not implement it automatically.

A clear dividing line emerges: SAML controls human users' access to AI applications, while OAuth and OIDC become the identity language for agents acting on their behalf. Both layers must be coherent — the gap between them is an attack surface.

Why does it matter?

It is tempting to treat SAML as a relic now that new projects reach for OIDC and JWT tokens by default. That would be a failure of perspective. Industry estimates suggest roughly two-thirds of enterprise environments still base their login policy on SAML to some degree, and in large organizations with legacy systems the share is higher still. These are approximate figures from market analyses rather than a hard measurement, but the scale of dependency is real and will not vanish within a few years.

More important is what SAML teaches about the nature of identity federation itself. An architecture in which trust reduces to a single signing key shows that the identity provider becomes a single point of catastrophe — and that an attack on it, like Golden SAML, can be far more damaging than stealing individual passwords. This lesson transfers one-to-one to the OIDC world and to every future federation. In practice SAML and OIDC increasingly coexist, with bridging layers translating XML assertions into JWT tokens. For an engineer this means that knowing SAML is not archaeology but a condition for safely operating the environments that actually handle login for millions of employees today.

SAML 2.0 is a mature, well-understood standard that, despite two decades of age, remains the core of enterprise login. Its strength lies in formal rigor and signature verifiability, and its weaknesses almost always lie in implementation, not in the specification itself.

Sources

• OASIS — Security Assertion Markup Language (SAML) v2.0 Technical Overview — link
• Okta — What is SAML and how does it work? — link
• Auth0 — SAML Authentication — link
• CyberArk — Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Apps — link
• Semperis — Silver SAML: Vulnerability in Microsoft Entra ID — link
• Wikipedia — SAML 2.0 — link
• IETF — RFC 6749: The OAuth 2.0 Authorization Framework — link
• OpenID Foundation — OpenID Connect Core 1.0 — link
• IETF — RFC 7644: System for Cross-domain Identity Management (SCIM) Protocol — link
• IETF — RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) — link
• SPIFFE — SPIFFE Overview — link
• Microsoft Learn — Workload identities in Microsoft Entra — link
• CISA — Emergency Directive 21-01: Mitigate SolarWinds Orion Code Compromise — link