SAML vs OAuth: The SSO Showdown

SSO (Single Sign-On) is so ubiquitous today that it is hard to imagine a world without it. In the olden days before SSO, users had only one option when landing on a new service. They were forced to sign up with an email address or a username and a password. Then, they would have to enter those credentials every time they needed to log back in.

Creating a new account is often a barrier of entry that services are looking to eliminate. By allowing signing on using a third-party identity provider, Web services reduce the bounce rate of new users. Specifically, new users who do not wish to go through the process of signing up just to try a service.

These days most web services offer a wide array of options for signing on such as registering and with your Google, Facebook, or Twitter accounts (among others).

SAML and OAuth both provide an opportunity for Single Sign-On, but they have significantly different use cases. While SAML is specifically designed for this purpose, OAuth can serve a similar function provided certain steps are taken.

It is imperative to choose the correct technology for the task you are trying to achieve. Making changes to sign-on processes when you have a large user-base can be quite a hassle.

In this post, we’ll outline the key differences between the two, and present the different use cases in which you might want to use each.

Authentication vs Authorization

Before we take a deep dive into SAML and OAuth let’s take a quick detour to remember what Authentication and Authorization are, how they differ, and how they are used.

Authentication is the process of identifying the user and the fact that they are present. In the real world, this is often done by showing your passport or driver’s license. The online equivalent is to ask the user for their credentials. By asking the user for a username and password, the user proves they are who they say they are, and that they are present.

Authorization is the process of granting access to information based on a one-time grant of rights. In real life, this can be a sticker on your car that means your vehicle is authorized to park in the company parking lot. It doesn’t matter if you are in the car or not, the car is authorized to be there. Online this could mean that you grant Facebook access to your Gmail contacts or a web-based photo editor access to your Google Photos.

SSO is a process of Authentication, not authorization. If you are signed on to one service, you are signed on to all of them. From the user’s perspective, this means they only need to enter their credentials once.

What is SAML2.0?

SAML2.0 is the latest version of a federation-level authentication protocol. Adopted by OASIS Open in 2005, SAML remains a prime choice for enterprise services. The idea behind SAML is a Single Sign-On through an identity provider. 

The most common use case is when a company needs to grant their employees access to many service providers. If this is done without SAML then the employees will each need many sets of credentials to access those different services. And as we know, when users need to remember many passwords they get written down or become very weak.

SAML allows users to sign-on to a multitude of services using one set of credentials, which is essential for security. The end-user will of course also benefit from not having to sign in multiple times during their workflow and only having to remember one password.

How does SAML2.0 work?

SAML is built over the foundation of trust between the Identity Provider (IDP) and the Service Provider (SP). Without the SP trusting the IDP SAML does not work. Not only that, the SP and IDP need to agree on using the same set of attributes to identify users, as both IDP and SP need to maintain a listing of their users.

There are several workflows that a user can go through to gain access to a service using SAML, but the most common one is as follows:

Imagine a visitor in a government facility. They arrive at the facility and the guard at the gate asks to see credentials. The visitor shows them some papers allowing access and an ID proving they are who they say they are. The guard gives the visitor a visitor’s ID.

Now when the visitor arrives at a locked door, they present their visitor’s ID. The electronic door contacts the main server to see if the visitor’s ID is valid, and checks if they are allowed access through this specific door.

This is a fairly good metaphor for how SAML works. The missing steps all happen behind the scenes. The user might try to access the service before signing on to the identity provider, so the service provider will automatically redirect the user to the identity provider to sign-on. This can happen because SAML is a standard supported by OASIS, and as such the browser knows how to handle it.

What is OAuth2?

OAuth is an authorization protocol. The purpose of it is to grant one service access to information another service has. Back before OAuth was designed, users would have to enter their credentials from one service directly into another.

This practice would seem absurd by today’s standards. This is an actual screenshot from Facebook asking for your Gmail credentials to extract your contacts.

How does OAuth2 work?

The above practice is completely obsolete today. Instead of entering your credentials, OAuth will redirect the user to the requested service, where the user will be asked by that second service if they wish to grant the access.

If the user authorizes this data access then the first service is granted an Authorization token from the second service, transparent to the user. 

This Authorization doesn’t usually expire on its own, which is why an Authorization token is not a valid means of Authentication. As you may recall Authentication requires the user to be present. If a token does not expire, there is no way to make sure the user is present.

SAML or OAuth? Which to use & when

While SAML was designed as an SSO, OAuth can be used for Authentication as well. Google, for example, uses OpenID Connect as a layer on top of OAuth to use it as an Authentication protocol. 

In general, SAML is used for enterprise services at the corporate level, while OpenID Connect and similar protocols built on top of OAuth are used for public-facing services.

On the Authorization side of things, SAML can likewise be used for Authorization. While OAuth was designed for Authentication, SAML can grant Authorization tokens.

If your primary need is Authorization then OAuth is a natural choice. However, if your need is Authentication, both can serve that purpose. So your decision would be based on the various services you intend to connect to. 

If your service is intended for use at the corporate level, SAML will likely allow the service to be integrated into many existing federation authorization platforms. However, if your service is intended for public use, using OpenID Connect allows users to sign-on with Identity Providers like Google.

Single Sign-On is a powerful tool that can help both the security and end-user experience. But it is important to use the right tool for the job. Remember that OAuth is not an authentication protocol so an additional layer is needed to make it one. 

There are common pitfalls when trying to use OAuth for Authentication. However, when it comes to Authentication in the corporate world, there is no competition for SAML. Your choice of one protocol or the other is largely dictated by your use case.