The Difference Between SAML 2.0 and OAuth 2.0

In this blog entry we take a little deeper look at the most prevailing standards for the use case of granting access to an online application. We’ll discover what is the difference between SAML 2.0 and OAuth 2.0.

What is SAML?

SAML 2.0 (Security Assertion Mark-up Language) is an umbrella standard that covers federation, identity management and single sign-on (SSO). In contrast, the OAuth (Open Authorisation) is a standard for, colour me not surprised, authorisation of resources. Unlike SAML, it doesn’t deal with authentication.

The table below lists a rough comparison of typical use cases for each of the standards. Even though SAML was actually designed to be widely applicable, its contemporary usage is typically shifted towards enterprise SSO scenarios. On the other hand, OAuth was designed for use with applications on the Internet, especially for delegated authorisation.

 

Use case type	Standard to use
Access to applications from a portal	SAML 2.0
Centralised identity source	SAML 2.0
Enterprise SSO	SAML 2.0
Mobile use cases	OAuth 2.0 (preferably with Bearer Tokens)
Permanent or temporary access to resources such as accounts, files	OAuth 2.0

 

However, both can be used for web SSO, providing single sign-on for multiple web applications. We will go through a practical example with both of the methods in order to highlight the pros and cons of both solutions.

First, a little refresher on terminology. SAML and OAuth use differing terms for the same basic concepts. The players in the SSO game are:

 

Term in SAML	Term in OAuth	Description
Client	Client	For example a web browser that an end user uses to access a web application
Identity Provider (IdP)	Authorisation Server	Server that owns the user identities and credentials
Service Provider (SP)	Resource Server	The protected application

 

How SAML works – the authentication workflow

1. An end user clicks on the “Login” button on a file sharing service at example.com. The file sharing service at example.com is the Service Provider, and the end user is the Client.
2. To authenticate the user, example.com constructs a SAML Authentication Request, signs and optionally encrypts it, and sends it directly to the IdP. The IdP verifies the received SAML Authentication Request and, if valid, presents a login form for the end user to enter their username and password.
3. The Service Provider redirects the Client’s browser to the IdP for authentication. Once the Client has successfully logged in, the IdP generates a SAML Assertion (also known as a SAML Token), which includes the user identity (such as the username entered before), and sends it directly to the Service Provider.
4. The IdP redirects the Client back to the Service Provider.
5. The Service Provider verifies the SAML Assertion, extracts the user identity from it, assigns correct permissions for the Client and then logs them into the service.

 

 

All done. Note that the SP never processed or even saw the Client’s credentials. Here we succeeded logging in with two redirects. The rude awakening comes when we want to move from a web application to a native one, such as a mobile app.

The devil in the detail lies within the step 6. There are two ways the IdP can redirect the Client back to the SP: HTTP Redirect and HTTP POST. The first one is not recommended, since the length of the HTTP Redirect URL is limited, and there is no standard telling what exactly is the maximum length. The second way avoids data size issues, but is very archaic to use. Either the user has to click a button to submit the POST form, or it has to be automated using JavaScript. This isn’t that big of a problem when dealing with web applications, but on a mobile application the authentication would simply fail, as the applications do not have access to the POST data and for a good reason.

There are possible (complex) workarounds, but the best solution might be to use OAuth instead.

The OAuth workflow

Critically, OAuth doesn’t assume that the Client is a web browser.

The example workflow proceeds now as follows:

1. An end user clicks on the “Login” button on a file sharing service at example.com. The file sharing service at example.com is the Resource Server, and the end user is the Client.
2. The Resource Server presents the Client with an Authorisation Grant, and redirects the Client to the Authorisation Server
3. The Client requests an Access Token from the Authorisation Server using the Authorisation Grant Code
4. The Client logs in to the Authorisation Server, and if the code is valid, the Client gets an Access Token that can be used request a protected resource from the Resource Server
5. After receiving a request for a protected resource with an accompanying Access Token, the Resource Server verifies the validity of the token directly with the Authorisation Server
6. If the token was valid, the Authorisation Server sends information about the Client to the Resource Server

 

 

We can now skip the awkward HTTP POST dance, but only at the price of an additional round trip to the Authorisation Server. This is caused by the different underlying trust models and their embodiments, the tokens. SAML Assertions or “SAML tokens” contain the user identification information (which can be trusted because it is signed), while with OAuth the Resource Server needs to make additional round trip in order to authenticate the Client with the Authorisation Server.

What if you can’t choose between SAML authentication and OAuth? Good news, one can always use both. In this scenario, the SAML Assertion can be used as an OAuth Bearer Token to access the protected resource. In addition, if the lack of authorisation is the only thing holding back on your OAuth implementation, be sure to check out OpenID and OpenID Connect, open standards that builds upon OAuth in order to provide just that.

My next blog is about how OpenID builds upon OAuth 2.0. Subscribe to our newsletter (on the top right) to get the latest news, blog releases, whitepaper publications etc.

 

Further resources:

Free whitepaper

• SAML vs OAuth vs OpenID Connect

IDaaS (SaaS delivered IAM)

• Take a look at Ubisecure IDaaS – the simplified, fast to implement single or multi-tenant Identity-as-a-Service for web, mobile and desktop applications

Sample Apps & OAuth & OpenID Connect Libraries

• JavaScript Single Page Application (SPA)
  Example of a JavaScript Single Page Application that uses OpenID Connect 1.0 for logon and then invokes an OAuth 2.0 protected API.
• API protection with OAuth 2.0
  Example of a simple OAuth 2.0 protected API. Token introspection is used in this example to validate OAuth 2.0 bearer tokens.
• Examples
  The single page application is deployed on GitHub Pages and the API runs on a free-of-charge tier of Azure.

 

Contact Us to talk to an expert about how you can easily start using both SAML and OAuth. As well as WS-Federation, OpenID Connect (OIDC) and GSMA Mobile Connect.

Request Demo to see how the Ubisecure Identity Platform and IDaaS (SaaS delivered IAM) can simplify the use of  all the authorisation protocols developers could use when building applications.

Read our update to this blog, The differences between SAML, OAuth and OpenID Connect.

 

Download the white paper: SAML vs OAuth vs OpenID Connect