SAML 2.0 vs SAML 1.1 - What’s the difference between the SAML versions?

SAML, or Security Assertion Markup Language, is an open standard for exchanging authentication and authorization data between an identity provider and a service provider.  

There are two main versions of SAML — SAML 2.0, released in 2005, and SAML 1.1 released in 2002. These days, when people talk about SAML, they’re usually referring to SAML 2.0, and for good reason. It has better security features and standardization, it explicitly defines how to authenticate users through a wide range of bindings, profiles, and protocols.

In this article, we’ll discuss the key distinctions between these two SAML versions to understand why SAML 2.0 was introduced.

Quick Overview: The differences between SAML 2.0 and SAML 1.1

Below are the differences between SAML 2.0 and SAML 1.1:

• SAML 2.0 messages can be signed and encrypted in their entirety, SAML 1.1 messages cannot.
• SAML 2.0 supports a wider range of attributes such as a user’s roles while SAML 1.1 only supports a limited number of attributes, typically indicating only who was authenticated, how, and when.
• SAML 2.0 supports many more bindings like HTTP Redirect (GET), SAML URI, and reverse SOAP. SAML 1.1 only defines a SOAP binding explicitly.
• SAML 2.0 supports Single Logout (SLO) while SAML 1.1 doesn’t.
• SAML 1.1 offers two web browser SSO options — the browser/artifact and browser/POST profiles. SAML 2.0 offers a more enhanced SSO profile and introduces other profiles including name identifier mapping, identity provider, Single Logout, and artifact resolution profile.
• SAML 2.0 supports metadata while SAML 1.1 doesn’t.

What is SAML 2.0?

When SAML 1.1 was released in 2002, it quickly gained popularity as an open standard for exchanging authentication and authorization data between security domains. However, developers soon discovered several issues with SAML 1.1, including:

• Lack of flexibility: SAML 1.1 was tightly coupled to SOAP, making it hard to use with other non-SOAP protocols. It also only has three types of messages, authentication request, authentication response, and attribute query which didn’t account for other scenarios like logging out.
• Limited authentication options: SAML 1.1 mostly focused on username/password authentication and had limited support for other authentication methods.

To address these issues, OASIS released SAML 2.0 in 2005. SAML 2.0 simplified the standard, decoupled it from SOAP, and added more flexibility in how assertions could be requested and returned by factoring out the binding aspects of each profile into a separate Bindings specification.

Key Benefits of SAML 2.0

Some of the main benefits of SAML 2.0 over SAML 1.1 include:

• Better standardization — SAML 2.0 supports both SOAP and non-SOAP bindings. It also introduced more profiles beyond the web browser SSO profile and standardized how IdPs and SPs exchanged metadata.
• Improved security — SAML 2.0 fully supports X.509 certificates and allows you to encrypt the entire assertion.
• Backward compatibility — SAML 2.0 is backward compatible with SAML 1.1, allowing for gradual migration.

What is SAML 1.1?

SAML 1.1 was first released in 2002 as a standard for exchanging authentication and authorization data between an identity provider and a service provider. It allowed single sign-on (SSO) across domains. SAML 1.1 uses XML-based assertions, protocols, and bindings to accomplish this.

And while SAML 1.1 accomplished basic SSO functionality, the standard was vague in places such as metadata exchange and session management.

Key differences between SAML 2.0 vs SAML 1.1

Below is an in-depth look of some of the key differences between SAML 2.0 and SAML 1.1:

Protocols

SAML 1.1 only specified queries that you could use to obtain SAML assertions.

SAML 2.0 introduced a more comprehensive set of protocols for a wide range of scenarios including:

• Authentication request protocol: In SAML 1.1 Web Browser SSO profiles are initiated by the IdP so you’d receive a SAML response out of nowhere. With SAML 2.0, an SP can issue an explicit authentication request of a user from an IdP.
• Assertion query and request protocol: Allows you to query an IdP for assertions about users.
• Artifact resolution protocol: Addresses the challenge of securely transporting SAML messages (especially large ones) by allowing you to exchange a small artifact (a reference to the SAML message) for the actual message directly from the IdP.  However, very few SPs support this protocol, largely because it’s a huge pain to debug.
• Single logout protocol: Perhaps one of the significant additions in SAML 2.0, it specifies how to logout users  from all the active sessions initiated via SSO with a single action.
• Name identifier management and mapping protocols: Enable the management (creation, modification, and deletion) and mapping of name identifiers (user identities) across different domains.

Bindings

A SAML binding defines how information is transmitted between the IdP and the SPs.

SAML 1.1 explicitly defines the SAML SOAP (Simple Object Access Protocol) binding. This binding is used to transport SAML messages within SOAP envelopes, typically for back-channel communication between IdP and SP.

And although not fully fleshed out, SAML 1.1 also included the precursors to other types of bindings such as HTTP POST, HTTP Redirect and HTTP Artifact. The issue was these bindings were not standardized.

SAML 2.0 refined and standardized these bindings. For Web Browser SSO, the most commonly used bindings are HTTP Redirect and HTTP POST binding:

• HTTP Redirect (GET) binding: Allows SAML requests and responses to be transmitted in the URL. This binding is suitable for short messages since URL length is limited.
• HTTP POST binding: SAML messages are sent in HTTP POST requests. Suitable for longer messages, for example those containing signed or encrypted assertions. This is the most commonly supported binding.
• HTTP Artifact binding: This rarely-implemented binding uses the Artifact Resolution Protocol and the SAML SOAP binding. Instead of sending the full SAML request to the IdP through the user's browser, the SP generates a smaller, fixed-length reference called an "artifact" that represents this request.
• Reverse SOAP (PAOS) binding: Designed to support scenarios where the SP acts as an HTTP requester but still needs to receive unsolicited responses initiated by the IdP.

These bindings allowed for more sophisticated communication between the IdP and SP and consequently enabled features such as Single Logout.

Profiles

SAML profiles specify how SAML assertions, protocols, and bindings can be combined to address specific use cases or scenarios, such as Single Sign-On (SSO).

SAML 1.1 defines the browser/artifact and browser/POST profiles specifically for SSO

SAML 2.0 introduced an enhanced Web browser SSO profile that provides a more standardized profile with a detailed specification for initiating SSO and SLO from either the IdP or the SP. This version also provided new profiles including:

• Assertion query/request profile: Specifies how SPs can request assertions about a specific user from IdPs.
• Single Logout (SLO) profile: Specifies how to log out users from their sessions.
• NameID management profile: Specifies how to update or change user data.
• Identity provider discovery profile: Specifies how SPs can retrieve information about a user’s IdPs.

Assertion and attribute sharing

In SAML 1.1, an assertion is somewhat basic. It typically contains information about who was authenticated, how, and when. It’s limited, in that it can’t carry complex attributes about the users.

Here's a simplified example of what a SAML 1.1 assertion might look like:

This assertion indicates that a user identified by user@example.com has been authenticated. While it communicates the essential details, it doesn’t include detailed user attributes (e.g., roles, department), limiting its use in situations where attribute access control is needed.

A SAML 2.0 assertion can carry multiple attribute statements, each potentially containing multiple attributes with complex data types. This is crucial if your app requires detailed user information for access control decisions.

Here's an example of a SAML 2.0 assertion:

In this SAML 2.0 assertion example, you can see how attributes such as role and department are explicitly defined, allowing for a more granular control over the information you receive from your customer’s IdP.

Session and logout management

SAML 1.1 primarily relies on your app to handle the user session and manage logouts. After a user is successfully authenticated, you’ll create a session for the user (e.g by setting a session cookie), track it internally to log out the user once the session expires.

SAML 2.0 offers session indexing which allows an IdP to keep track of sessions established with the various SPs connected to it. It’s what enables the Single Logout (SLO) feature, where a logout request initiated from any SP or the IdP itself can lead to the termination of all sessions across SPs for that user.

Here’s how it works: When a user logs in via SSO, the IdP generates a session index and includes it in the SAML authentication response sent to your app. Your app must then extract this index and use it to reference the session locally.

<saml2:AuthnStatement SessionIndex="12345abcdef">

...

</saml2:AuthnStatement>

You should store the session index in association with the user's session. Then, when you receive an SLO request , you can use the session index to identify and terminate the correct session.

def logout_user(session_index):

   # Use the session index to find and invalidate the user's session

   ...

   return "User logged out"

Security

SAML 1.1 supports XML signatures to verify the origin and integrity of the SAML assertions but has limited encryption support.

In SAML 2.0, not only can entire SAML assertions be encrypted but also specific elements within an assertion. Additionally, you can also digitally sign the entire SAML response and request.

Metadata

Metadata provides information about an IdP and SP, service endpoints, protocols supported, and information about keys used for signing and encryption. It’s typically exchanged between the IdP and SPs during the initial set up phase to allow for automated configuration.

Metadata is what makes SAML work so well:

• If you want to know where to send the user with the authentication request, you can look it up in the IdP’s metadata.
• If an IdP wants to know whether an SP is valid, it looks it up in the list of trusted SPs in the metadata.
• To know where to send the user with the authentication response, the IdP looks up the endpoint location of the SP in metadata, and so on.

SAML 1.1 did not have a standardized way of defining metadata.

FAQs

Is SAML 1.1 still in use?

Rarely. Most implementations have upgraded to SAML 2.0.

Is there any benefit to sticking with SAML 1.1?

No, SAML 2.0 is superior in nearly every way.

It provides improved security, flexibility, and interoperability. SAML 2.0 uses XML encryption and digital signatures to better protect messages. It also supports fine-grained attribute access control, Single Logout, metadata, and has better session management.

Is there a SAML 3.0?

Not currently. SAML 2.0 is the latest version and still meets most needs.

Conclusion

SAML 2.0 has become the de facto standard for web SSO and federation and most organizations have migrated from SAML 1.1 to SAML 2.0.

With WorkOS unified SSO you can add enterprise-grade SAML SSO authentication for any of your customer’s identity provider (like Okta, Microsoft Entra, and OneLogin) within minutes using a single API-based integration.

• Get started fast: With SDKs in every popular language, easy-to-follow documentation and Slack-based support, you can implement SSO in minutes rather than weeks.
• Support every protocol: With OAuth 2.0 integrations to popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML/OIDC connections, WorkOS can support any enterprise customer out of the box.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they bring 10 or 10,000 SSO users to your app.

Explore Unified SSO by WorkOS.