SAML vs OAuth Introduction

Authentication is an important aspect of many systems, and sufficiently effective and secure authentication processes are vital for the operations of a huge number of companies and organisations. There are currently two main standards used for federated authentication—SAML and OAuth. The majority of systems will use one or the other of these two technologies. 

Although SAML and OAuth are used for similar purposes, there are differences between the two that you may want to consider when choosing an authentication method for your organisation. In this guide, we will look at exactly how each of these technologies works and which may be the best for your needs.

What is Federated Authentication?

OAuth explained

OAuth is short for Open Authorisation. It is an open standard that can be based on binary, JavaScript Object Notation (or JSON), or even SAML.

OAuth was first launched in 2006 as a component of the OpenID implementation that is used by Twitter. In 2010, OAuth 1.0 was released, and OAuth 2.0 followed in 2012 and is the latest version at the time of writing. The terms “OAuth” and “OAuth 2.0” are often used interchangeably, such as in this article. OAuth uses HMAC-SHA—or Hash-based Message Authentication—signature strings. 

OAuth works by defining four distinct roles; Resource Owner (a user who authorises a site or application to access their account), Client (the application itself that accesses the user’s account), Resource Server (the server that hosts the user’s resources), and Authorisation Server (the server that verifies the Resource Owner’s identity via their login credentials, and issues OAuth Bearer Tokens to the Client).

The OAuth workflow

The OAuth workflow is as follows:

• The client sends a request to the Resource Owner to access a resource held on the Resource Server.
• If the request is granted by the Resource Owner, an authorisation token known as an OAuth Bearer Token is granted to the Client.
• The Client uses this token to request an access token from the Authorisation Server’s API (Application Programming Interface).
• The Authorization Server verifies the identity of the Client.
• If this identity is valid, the Client receives an access token.
• The access token is used by the Client to request access to a resource held by the Resource Server.
• If the access token is valid, the Resource Server grants this access to the Client.

SAML explained

The SAML workflow

The SAML workflow is as follows:

• The user of (for example) a website clicks “Log In”. In this case, the website would be the SP and the user the “client”.
• The SP (website) creates an encrypted authentication request and sends it to the IdP.
• The SP (website) redirects the user’s browser to the IdP.
• The IdP carries out verification of the SAML authentication request. 
• Once the authentication request has been verified as valid, the IdP provides a login screen for the user to enter their credentials (e.g. username and password).
• After the login has been carried out successfully, the IdP generates a SAML “token” representing the identity of the user.
• The IdP sends this token to the SP.
• The IdP redirects the user to the SP.
• The SP verifies the token and assigns the correct access permissions to the user.
• The user is logged into the service.

SAML vs OAuth: The difference between SAML 2.0 and OAuth 2.0

The main difference between SAML and OAuth is that SAML covers identity management, SSO, and federation, whereas OAuth deals specifically with authorisation and not authentication.

Authentication vs Authorisation 

The terms “authorisation” and “authentication” are sometimes used interchangeably, however they are actually two different Identity and Access Management (IAM) processes.

Authentication is the process of a user’s identity being verified, whereas authorisation is the granting of specific access permissions to that user. Authentication includes techniques like SSO, MFA, and OTP (one-time passwords). Authorisation takes place after authentication.

Both processes play vital roles in an Identity and Access Management strategy. A simple way to remember which is which is to think of it this way; authentication is about the “Identity”, and authorisation is about the “Access”!

Is OAuth better than SAML?

The question of which standard is preferable is not a simple one. There is not a straightforward answer, as different organisations have different needs. 

Both standards can be used as part of an SSO setup, but there are advantages of each. For example, SAML is generally considered to be more straightforward and secure, while OAuth is particularly suited towards mobile use. 

SAML makes use of cookies that grant users access to platforms/applications across different domains. This means that administrative costs are reduced, and IT managers are more able to configure on-premise and/or cloud-based applications to be included in SAML’s SSO. Organisations that use Virtual Desktop Infrastructure (or VDI) implementations may find SAML more useful due to the ability to incorporate off-premise applications into the federation.

The area in which OAuth provides the most benefits is in access scoping. If an organisation needs to configure a customised system of granting different users different levels of access to resources, some of which may only be temporary, OAuth is designed specifically for this through its use of API calls.

OAuth is also designed more for IoT (Internet of Things) devices such as mobile phones, tablets, and video games consoles than SAML is.

Can OAuth be combined with SAML?

So, can you use SAML and OAuth together? The simple answer is “yes”! 

In order to do this, you can specify the SAML token to be recognised as an OAuth Bearer Token by OAuth’s Authorisation Server, which will grant the user access to resources. This means that you do not necessarily have to choose between either a SAML implementation or an OAuth one.