SAML vs OAuth
SAML — Security Assertion Markup Language
OAuth — Open Authorization
If you have some understanding on SAML and OAuth, you may have found it an incomparable battle. Yes, though both SAML and OAuth deal with Identity and Access Management(IAM) they focus on different aspects. In this post I am to share a bit of history around these protocols to understand the motives, how they evolved, how they are related to each other and future directions I see.
If you have come across SAML and OAuth, most probably you had some requirements around user authentication, single sign on, authorization or access delegation. Let’s first start clearing out the basic intentions of these before jumping to the depths.
SAML -> A protocol designed to provide Single Sign On(SSO) that focuses on user authentication, user attributes and authorization.
OAuth -> An authorization framework which provides access delegation approaches. (This later paved the path to OpenIDConnect protocol which addresses user authentication and SSO. More details later.)
As we can see there is a basic mismatch in what we try to achieve using the two standards. At this occasion, let me introduce two other members in the space, which can be thought as fair opponents which are OpenID and OpenIDConnect(OIDC). Let’s place these standards/protocols in a timeline to understand how and why they evolved that way so we can do a much convincing and useful comparison for the current world.
Timeline
Above diagram is extracted from a presentation(https://slideplayer.com/slide/11156130/) done by Eve Maler, who is an editor of the SAML 2.0 specification itself and several more that followed.
If we look at the pre-SAML era, XML was the dominant standard used in communications between systems. For authentication and authorization requirements this was the same, but different enterprises used different XML formats. That is when people realized the importance of a common format, which will enable interoperability between the systems in authentication and authorization(AA) aspects. OASIS(Organization for the Advancement of Structured Information Standards) — Security Services Technical Committee (SSTC) had put together SAML V1.0 as an outcome of an effort started towards this in January 2001. Then Liberty Alliance, a large consortium of companies have proposed an extension to the SAML standard with it’s Liberty Identity Federation Framework (ID-FF), which has largely contributed to the SAML standard in documenting the identification process of a user. Next big contribution has been from Shibboleth who have been trying to address the same requirement in the education domain, that has extended the IDP-initiated flow of SAML to be SP-initiated as well. This SP-initiated flow is the most widely configured use case in my opinion and is a great contribution to the whole industry. With all these coming together to improve the specification we finally have SAML 2.0 with few erratas as of now, working fine for user convenience and smooth system integrations without compromising on security. With wide adoption of the protocol, there are several other specification built around this which we will address in brief in the comparison below.
Within the above timeline we don’t hear much of about other protocols, until OpenID 1.0 comes out in 2006. I am putting the timeline there onward below.
Brad Fitzpatrick has laid the foundation for OpenID in May 2005 with the name of ‘YADIS’, Yet Another Distributed Identity System. While supporting decentralized identity verification without having the limitation to be browser based, OpenID had gained lot of traction at the time with several giants contributing to and adopting the protocol. Twitter’s adoption of OpenID and several others with access delegation requirements, has paved path to OAuth 1.0 when they realized there is no open standard for access delegation. Been initiated in November 2006, OAuth went through lot of deliberation and improvements with the contributions from the industry until it finally get released as OAuth 1.0 in April 2010. It used digital signatures to ensure security and these cryptographic requirements made it less popular among the developers. OAuth 2.0 came to remove this barrier, with short lives access tokens and depending on HTTPS rather than having complex cryptographic involvements. OAuth 2.0 is backward incompatible with OAuth 1.0, but gained lot of affection from the industry and is widely adopted.
All this time SAML was there, playing it’s role providing Single Sign On functionality running in a separate track and specifically dominating education domain. But the industry was gradually turning towards JSON as the common format moving away from verbose XML format, which raise the requirement for SAML in JSON if I may say, which paved the path to OpenIDConnect 1.0.
Since OpenID is already kind of a dead protocol with almost all of the giants in the industry retiring it around 2018, I will not dig much into it. It introduced a decentralized authentication flow for users in it’s attempt to let the user control what provider they use to prove their identity -> User-centric identity as we call it today. (Later it has seemed users were much OK with using Facebook or Google for OpenID login, than fully utilizing the capabilities).
With the popularity of OAuth 2.0 protocol, there has been two attempts to extend OpenID protocol to OAuth defining extensions, but only the other way has worked out which is to define an authentication protocol on top of OAuth 2.0 protocol. The outcome is what we have today, OpenIDConnect 1.0 specification and many that followed up.
SAML vs OpenIDConnect
As you may have realized now, this is the fair comparison. Both of these protocols supports cross domain web SSO and identity federation.
- SAML is XML in format / OpenIDConnect is JSON in format.
- User flow is same in both the basic flows.
- Force authentication supported by both (forceAuth parameter in SAMLRequest, prompt=login/consent in OIDC. Advantage is OIDC protocol has thought of user consents as well.)
- Passive authentication supported by both. (IsPassive parameter in SAMLRequest, prompt=none in OIDC)
Additionally OIDC has below,
- OIDC session management profile to define how to check and keep the application session in sync with the IDP session.
- Client Initiated Back-channel Authentication (no necessity for browser interactions for the user)
Also some industry domain focused profiles are present from OIDC,
- 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 have been lot of developments happening around OIDC protocol, SAML is still a widely used protocol, specially in the education sector. Though my post might have some bias towards OIDC, SAML has been there in industry serving for decades now. There is no argument that SAML is a very robust and a useful protocol, that CAN still serve the demands in the modern world, though we may have a better option to go for.
Sample OIDC Response
Sample SAML Response
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6" Version="2.0" IssueInstant="2014-07-17T01:01:48Z" Destination="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685">
<saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75" Version="2.0" IssueInstant="2014-07-17T01:01:48Z">
<saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
<saml:Subject>
<saml:NameID SPNameQualifier="http://sp.example.com/demo1/metadata.php" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ce3d2948b4cf20146dee0a0b3dd6f69b6cf86f62d7</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2024-01-18T06:21:48Z" Recipient="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2014-07-17T01:01:18Z" NotOnOrAfter="2024-01-18T06:21:48Z">
<saml:AudienceRestriction>
<saml:Audience>http://sp.example.com/demo1/metadata.php</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2014-07-17T01:01:48Z" SessionNotOnOrAfter="2024-07-17T09:01:48Z" SessionIndex="_be9967abd904ddcae3c0eb4189adbe3f71e327cf93">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>Note: This will be signed and optionally encrypted.
SAML Specifications — http://docs.oasis-open.org/security/saml/v2.0/
OpenIDConnect Specifications — https://openid.net/developers/specs/
In my opinion, OIDC is the current best option we have, specially with micro-services been heavily benefited with self contained JWT tokens, I think it will stay same for a while.
Additionally nowadays we do not have stick to SAML even if the legacy systems are still using SAML, as we have mediation capabilities among the protocols.
Ref:
https://slideplayer.com/slide/11156130/
http://blog.facilelogin.com/2014/10/brief-history-of-openid-connect.html
