SAML — Security Assertion Markup Language

OAuth — Open Authorization

If you are familiar with SAML and OAuth, you may have discovered it to be an incomparable battle. Yes, while both SAML and OAuth deal with Identity and Access Management (IAM), their emphasis is different. In this post, I will share some background information about these protocols to better understand their motivations, how they evolved, how they are related to one another, and what future directions I see.

If you've come across SAML and OAuth, you likely had some user authentication, single sign-on, authorization, or access delegation requirements. Before delving into the depths, let us first clear out the basic intentions.

SAML -> A protocol designed to provide Single Sign-On(SSO) that focuses on user authentication, user attributes, and authorization.

OAuth -> An authorization framework that provides access delegation approaches. (This later paved the path to OpenIDConnect protocol which addresses user authentication and SSO. More details are below.)

As we can see, there is a fundamental misalignment between what we try to achieve using the two standards. On this occasion, I'd like to introduce two other members of the space who can be considered fair competitors: OpenID and OpenID Connect (OIDC). Let's put these standards/protocols in a timeline to see how and why they evolved, so we can make a much more convincing and useful comparison for today's world.

Timeline

SAML Specification Contributions and Evolution

The diagram above was taken from a presentation (https://slideplayer.com/slide/11156130/) provided by Eve Maler, an editor of the SAML 2.0 specification, and several others that followed.

In the pre-SAML era, XML was the dominant standard used in system communications. This was true for authentication and authorization requirements, but different enterprises used different XML formats. That is when people realized the importance of a common format for enabling system interoperability in authentication and authorization (AA) aspects. As a result of an effort begun in January 2001, the OASIS (Organization for the Advancement of Structured Information Standards) — Security Services Technical Committee (SSTC) developed SAML V1.0. Then, with its Liberty Identity Federation Framework (ID-FF), a large consortium of companies proposed an extension to the SAML standard, which has largely contributed to the SAML standard in documenting the user identification process. Shibboleth, which has been attempting to address the same requirement in the education domain, made the next significant contribution by extending the IDP-initiated flow of SAML to be SP-initiated as well. This SP-initiated flow, in my opinion, is the most widely configured use case and makes a significant contribution to the entire industry. With all of this working together to improve the specification, we now have SAML 2.0, which works well for user convenience and smooth system integrations without compromising security. With the protocol's widespread adoption, several other specifications have sprung up around it, which we will discuss briefly in the comparison below.

Until OpenID 1.0 is released in 2006, we don't hear much about other protocols in the timeline above. I'm putting the timeline from there on down below.

Timeline from OpenID to OpenIDConnect(OIDC)

Brad Fitzpatrick founded OpenID in May 2005 under the name YADIS, or Yet Another Distributed Identity System. While supporting decentralized identity verification without the restriction of being browser-based, OpenID gained a lot of traction at the time, with several industry titans contributing to and adopting the protocol. When Twitter realized there was no open standard for access delegation, they adopted OpenID and several others with access delegation requirements, paving the way for OAuth 1.0. Since its inception in November 2006, OAuth has undergone extensive deliberation and improvement with contributions from the industry before being released as OAuth 1.0 in April 2010. It used digital signatures to ensure security, and because of these cryptographic requirements, it was less popular among developers. OAuth 2.0 was designed to overcome this barrier by using short-lived access tokens and relying on HTTPS rather than requiring complex cryptographic involvement. OAuth 2.0 is incompatible with OAuth 1.0, but it has received a lot of love from the industry and is widely used.

SAML was present the entire time, serving as a separate track, providing Single Sign-On functionality, and specifically dominating the education domain. However, the industry was gradually moving away from a verbose XML format and toward JSON as the common format, which raised the requirement for SAML in JSON, if I may say, and paved the way for OpenIDConnect 1.0.

Since OpenID is already a kind of dead protocol, with almost all of the industry's giants abandoning it around 2018, I won't delve too deeply into it. It introduced a decentralized authentication flow for users in an attempt to give the user control over which provider they use to prove their identity -> User-centric identity, as it is now known. (It later appeared that users were more comfortable using Facebook or Google for OpenID login than fully utilizing the capabilities.)

With the popularity of the OAuth 2.0 protocol, there have been two attempts to extend the OpenID protocol to OAuth defining extensions, but only the other way, which is to define an authentication protocol on top of OAuth 2.0 protocol, has been successful.

The outcome is what we have today, OpenIDConnect 1.0 specification and the many that followed.

SAML vs OpenIDConnect

As you may have deduced, this is a reasonable comparison. Cross-domain web SSO and identity federation are supported by both protocols.

• SAML is XML in format / OpenIDConnect is JSON in format.
• User flow is the same in both basic flows.
• Force authentication is supported by both (forceAuth parameter in SAMLRequest, prompt=login/consent in OIDC. The OIDC protocol has the advantage of considering user consent as well.)
• Passive authentication is supported by both. (IsPassive parameter in SAMLRequest, prompt=none in OIDC)

In addition, OIDC has the following,

• To define how to check and keep the application session in sync with the IDP session, use the OIDC session management profile.
• Client-Initiated Back-channel Authentication (no necessity for browser interactions for user)

OIDC also provides some industry domain-specific profiles,

• Banking — FAPI (https://openid.net/wg/fapi/)
• Education — Research & Education (R&E) (https://openid.net/wg/rande/)
• Health — HEART (https://openid.net/wg/heart/)
• Mobile network operators — MODRNA (https://openid.net/wg/mobile/)

While there has been a lot of progress with the OIDC protocol, SAML is still a widely used protocol, particularly in the education sector. Though my post may be biased toward OIDC, SAML has been serving the industry for decades. There is no doubt that SAML is a very robust and useful protocol that CAN still meet the demands of today's world, though we may have a better option.

Sample OIDC Response

Encoded and decoded IDToken (from jwt.io)

Sample SAML Response

Note: This will be signed and optionally encrypted.

SAML Specifications — https://docs.oasis-open.org/security/saml/v2.0/

OpenIDConnect Specifications — https://openid.net/developers/specs/

In my opinion, OIDC is currently the best option we have, especially with micro-services benefiting greatly from self-contained JWT tokens; I believe this will continue for some time.

Furthermore, even if legacy systems continue to use SAML, we no longer need to adhere to it because we have mediation capabilities among the protocols.