SAML vs OAuth vs OpenID Connect — Which One Suits You the Most?

Stressing the importance of security is a hardly new concept. Almost on a weekly basis, we hear about new security breaches, data leaks, and other security failures. Of course, only some of them are caused by web applications but this is not the reason for putting less effort into securing them.

Today I will walk you through the three most common security protocols available. I will present their features, compare them, and suggest when and why one of them may be the best choice.

I will start by explaining the difference between the two most basic security concepts: Authentication and Authorization.

Authentication vs Authorization

The concepts of authentication and authorization are related to users and their desire to access particular resources.

• Authentication — is a process of proving our identity to security provider so we are interested in answering the question, “Who you are?”
• Authorization — is about proving that we have required roles/permission to access specific resources, so the question here is, “What can you do?”

The difference in meaning between those two concepts will be crucial when we start comparing protocols. Especially in the case of comparing OAuth with OpenID Connect.

Details of SAML

First of all, SAML is just an abbreviation from Security Assertion Markup Language. It is described as  an open standard for exchanging authentication and authorization information between interested parties — in particular, an identity provider and a service provider.

Originally created in 2002 by OASIS Security Services Technical Committee, it is the oldest one from the protocols discussed today. Since 2002 SAML has had two updates, one minor to version 1.1 in 2003 and one major to version 2.0 in 2005. As for now SAML 2.0 is an official standard adopted by OASIS.

There are four most important concepts in SAML – most of them underwent significant changes between version 1.0 and 2.0:

• Security Assertions — facts that are used by service providers to make access-control decisions. They are written using XML syntax. We can differentiate three types of such facts: Authentication,  Attribute, and Authorization decision.
• Protocols — describe how certain SAML elements (including assertions) are packaged within SAML request and response elements, and give the processing rules that SAML entities must follow when producing or  consuming these elements. The most important type of SAML protocol is called a query. Similar to assertions there are also three types of queries: Authentication, Attribute, Authorization decision. Till SAML 2.0, which added and described 6 new protocols, queries were the only protocols specified by SAML.
• Bindings — a mapping of a SAML protocol message onto standard messaging formats and/or communication protocols. For example, the SAML SOAP binding specifies how a SAML message is encapsulated in a SOAP envelope, which itself is bound to an HTTP message. SAML 1.1 specified just one binding, the SAML SOAP Binding but SAML 2.0 brought a brand-new binding specification defining  6 different standalone bindings 
• Profiles — describes in detail how assertions, protocols, and bindings cooperate to support a defined use case. The most important profile is the Web Browser SSO Profile. Apart from the complete refactor of profiles, aimed to make them more flexible, SAML  2.0 gave us numerous new profiles.

As you can see there were some significant changes between different versions of the SAML protocol. Diving deeper into the mystery we can notice that those changes were aimed to make SAML 2.0 more flexible than 1.1 or 1.0 versions. Moreover, because of the scope of these changes SAML 2.0 and 1.1 are not compatible.

Additionally, there is a standard called Identity Federation Framework currently in version 1.2 contributed in 2003 by The Liberty Alliance. It was used as the basis for SAML 2.0 but again they are not compatible.

Details of OAuth

OAuth or Open Authorization originally published in April 2010 as RFC 5849 by IETF (Internet Engineering Task Force) is a protocol for authorization. It provides clients with "secure delegated access" to server resources on behalf of a resource owner. It also specifies a process for resource owners to authorize third-party access to their server resources without providing credentials.

In October 2012 we got the first major update of OAuth in the form of RFC 6749, and that was how OAuth 2.0 was created. Of course, OAuth 2.0 and 1.0 are not compatible, you did not expect that, did you?

As for now, OAuth 2.1 is in a draft state.

Nowadays, this standard is the most common one and is used by companies like Facebook or Google. Many of them use it as the only supported authorization protocols for example: all third-party Twitter applications have been required to use OAuth since 31 August 2010 and Facebook whose Graph API only supports OAuth 2.0.

There are four main concepts in OAuth:

• Resource owner — entity capable of granting access to protected resource. When the resource owner is a person, they are referred to as end-users.
• Resource server — server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
• Client — application making protected resource requests on behalf of the resource owner and with its authorization.
• Authorization server — server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

The interaction and relations between Authorization Server and Client are the most important part of OAuth. 

The last protocol which I want to mention today is OpenID Connect and is based on OAuth 2.0.

Details of OpenID Connect

Or OIDC an authentication protocol based on the OAuth 2.0 specification. Moreover, it is the 3rd generation of a tool called OpenID, which never became famous and widely used. Created in 2014 is the youngest of protocols from today.

Its main goal is “making simple things simple and complicated things possible”. It allows clients to verify the end-user’s identity based on the authentication performed by an Authorization Server. Additionally, it exposes REST-like API enabling us to get basic information about the end-user.

OpenID Connect works by adding OpenID scope value in the OAuth Authorization Request. Information about the authentication performed is returned as a JWT and called an ID Token. The two most important building blocks of OpenID flow are:

• OpenID Providers (Ops) -> OAuth 2.0 Authentication Servers implementing OpenID Connect
• Relying Parties (Rps) -> OAuth 2.0 Clients using OpenID Connect     

As a side note, I can give you a math equation for OpenID Connect:

(Identity, Authentication) + OAuth 2.0 = OpenID Connect

Difference Between SAML, OAuth, and OpenID Connect

1. The Biggest Difference

   SAML mainly looks like ready to work tool while both OAuth and OpenID Connect are more like specifications – describing particulars flows – which could be further implemented. What is more, OpenID Connect is built atop OAuth while OAuth itself and SAML are independent. Naturally, all three protocols are incompatible in any combination.
   A notable difference here is that OAuth specification seems to be low on details and leaves a   few important topics up to you when implementing your solution. This may lead to incompatible implementations of the same protocol so does not seem to be a particularly good idea. Fortunately, OpenID Connect filled some of those gaps.

2. Purpose
   

   SAML is a standard for exchanging both authentication and authorization information between interested parties. While OAuth is aimed to provide a mechanism for authorization only. Despite that in OAuth we can also achieve a thing called pseudo-authentication when we abuse authorization features to make authentication possible. To some extend this is exactly what OpenID Connect is doing but specification and process was change to be more secure and less confusing. Because the exact description of pseudo-authentication is out of the scope of this text here is the page where you can find more information. OpenID Connect adds an authentication layer over existing OAuth specifications effectively providing both authentication and authorization possibilities.

3. Complexity of Usage

   From my perspective as a software engineer SAML looks like the most complex to use and implement mostly because of the old-school approach to configuration - writing XML files and all the things related to protocols and bindings. While the case of OpenID and OAuth you use plain old HTTP and not so old JWT. I know that nowadays we have tools for everything but there may be cases where you need to do some low-level checks and trust me, you do not want to fight with auto-generated XMLs in such situations. On the other hand, OAuth itself does not provide authentication features so you will have to mix it with other protocols, which is quite problematic, or use pseudo-authentication – even more problematic.

4. Notable features
   

   Firstly, all three protocols seem to focus on supporting SSO. I may add that SAML was the first (ever) framework design to provide cross-domain SSO. Also, SAML allows us to integrate with tools like LDAP to “get” already defined user profiles. This feature is not included in the two other remaining protocols. On the other hand, SAML seems not to be the best choice for securing mobile and SPA applications. In fact, SAML is best suited for old-school applications with a traditional backend. It works this way mostly because of conceptual decisions taken years ago when such application types did not exist. Maybe SAML 3.0 if it gets created (or when) will add some additional possibilities here.

After this quite long comparison we can move to explaining when and why a particular protocol may be the best.

When to Choose the Exact Protocol

If you expect that I will provide you with a silver bullet solution for every case you will, unfortunately, be disappointed. As usual, I will give you some general guidelines and leave the final decision up to you.

First of all, if your application already uses SAML then go for SAML, any other mix will end with headache.

If you want to have many interactions with Google, Facebook or Twitter then OAuth and OpenID will be best suited. Keep in mind that if you rely heavily on authorization then OAuth will be a better solution while OpenID Connect would be better for authentication heavy integrations.

For mobile and SPA-type applications, OpenID Connect may be the best-suited protocol. However if you only want to secure your API the OAuth 2.0 may be better option.

Here you can read more about processes provided by OAuth and OpenID Connect and when they may be the biggest help for you.

Summing Up

The guidelines above are a good summary of today’s text. I tried to stay as objective as possible and not favor any particular solution. I hope that I gave you some additional knowledge about the most common present-day security protocols and that my guidelines will come in handy at some point. The final decision on choosing a tool to secure your application I leave up to you. Just remember to think through this decision because it may not be the easiest one to revert. Thank you for your time.