What Is the SAML 2.0 Authentication Protocol Used For?

For an IT department, SAML 2.0 addresses a practical question: how can an employee be given access to dozens of applications with a single authentication process, while centralising authentication policies through an identity provider?

What is SAML 2.0?

This centralisation of authentication is precisely what SAML standardises. Version 2.0 of the standard was approved by OASIS (Organization for the Advancement of Structured Information Standards) in March 2005 at its highest level of ratification. It brought together three earlier initiatives: SAML 1.1, the Liberty Alliance ID-FF 1.2 profile and contributions from the Shibboleth project. It was also adopted as an international recommendation by the International Telecommunication Union (ITU-T X.1141).

Technically, the SAML protocol is based on assertions: XML security tokens that describe a user, the “principal”, and their authentication. These assertions are exchanged between two roles:

• The Identity Provider (IdP), which authenticates the user.
• The Service Provider (SP), which is the application the user wants to access.

More than twenty years after its ratification, SAML 2.0 is not a legacy protocol. It remains widely deployed in businesses, the public sector and academia, where it continues to provide a foundation for identity federation.

How does SAML authentication work?

SAML authentication involves three parties: the user, the Identity Provider (IdP) and the Service Provider (SP). In the most common scenario, known as “SP-initiated” authentication, the exchange works as follows:

Trust between the IdP and the SP cannot be established automatically. It must be configured beforehand through an exchange of metadata, including certificates, endpoints and identifiers. This allows each party to verify the authenticity of the other party’s messages. The assertion’s cryptographic signature guarantees that it came from the expected identity provider and has not been altered.

Components of the SAML 2.0 standard

The SAML 2.0 standard consists of several complementary components:

• Assertions: the statements themselves, which can contain three types of information: authentication information, attributes such as a role, department or email address, and, less commonly, an authorisation decision.
• Protocols: the request and response messages used to carry assertions.
• Bindings: the methods used to transport these messages over the web, for example through an HTTP redirect or an HTTP POST request.
• Profiles: predefined combinations of components for a particular use case. The best-known example is the Web Browser SSO Profile.
• Metadata: the technical description exchanged between the IdP and SP to establish trust.

Although SAML can carry authorisation decisions, its main uses remain Single Sign-On and attribute exchange. Fine-grained authorisation is generally handled by other mechanisms.

SAML 2.0, OAuth 2.0 and OpenID Connect: what are the differences?

These three standards are often confused, even though they do not address the same question:

• SAML 2.0 deals with authentication and Single Sign-On. It is based on XML and is widely established in enterprise environments, cross-organisational federations and the public sector.
• OAuth 2.0 deals with authorisation. It delegates access to a resource (for example, “Can this application read my calendar?”) and does not handle authentication on its own.
• OpenID Connect (OIDC) adds an authentication layer to OAuth 2.0, allowing an application to establish a user’s identity, particularly through an ID token in JWT format. It is suitable for web and mobile applications, while API access relies on OAuth 2.0 access tokens.

In practice, SAML 2.0 and OpenID Connect coexist. SAML remains the standard for existing enterprise applications, while OpenID Connect is generally used for new developments. The choice between SAML, OAuth 2.0 and OpenID Connect depends on the type of application, its authentication requirements and how access to APIs must be delegated.

Implementing SAML 2.0 with Keycloak

The most common way to deploy SAML 2.0 without reimplementing the protocol is to use an Identity and Access Management (IAM) solution. Keycloak, a leading open-source solution in this field, can act as a SAML 2.0 identity provider. It also supports OpenID Connect, allowing legacy SAML applications and newer OIDC developments to share the same authentication service.

Clever Cloud offers Keycloak as a Service: a fully managed Keycloak service hosted in France and operated with the expertise of Please Open It, a partner specialising in Keycloak. This approach removes the burden of operating the identity server, including updates, availability and backups, from internal teams, while allowing them to retain control over SAML and OIDC settings.

“SAML 2.0 remains essential in enterprise environments because of its long history (2005) but also because of its network simplicity: everything passes through the user’s browser, with no direct connection required between the application and the identity server. In contrast, the modern OpenID Connect standard requires direct server-to-server communication to remain secure. OIDC’s ‘100% browser-based’ mode, the Implicit Flow, has now been abandoned because it is considered too vulnerable.”

Mathieu Passenaud
Co-founder at Please Open It

FAQ

Is SAML 2.0 still used in 2026?

Yes. Ratified in 2005, SAML 2.0 remains widely deployed in businesses, the public sector and academia for Single Sign-On and identity federation. It coexists with OpenID Connect, which is often preferred for new web and mobile projects.

What is the difference between SAML and SSO?

SSO, or Single Sign-On, is a principle: users authenticate once to access multiple applications. SAML is one of the protocols that can implement this principle across domains. OpenID Connect is another.

Does SAML handle authentication or authorisation?

It can handle both, but it is mainly used for Single Sign-On and attribute exchange. The protocol can carry authorisation decisions, although this capability is rarely used in practice.

Should I choose SAML 2.0 or OpenID Connect?

The choice primarily depends on the protocol supported by the application. SAML 2.0 is suitable for services designed to use SAML federation, while OpenID Connect is generally appropriate for authenticating users in web and mobile applications. OAuth 2.0 access tokens are used to control access to APIs. Both approaches can coexist behind the same identity provider, such as Keycloak.

Does Keycloak support SAML 2.0?

Yes. Keycloak can act as a SAML 2.0 identity provider and also supports OpenID Connect, allowing both protocols to be used together.