In this blog entry we’ll 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.

SAML (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.

 

SAML vs OAuth table

 

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:

 

SAML vs OAuth table 2

 

The SAML 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.
  3. The Service Provider redirects the Client’s browser to the IdP for authentication.
  4. The IdP verifies the received SAML Authentication Request and if valid, presents a login form for the end user to enter his username and password.
  5. 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.
  6. The IdP redirects the Client back to the Service Provider
  7. The Service Provider verifies the SAML Assertion, extracts the user identity from it, assigns correct permissions for the Client and then logs him in to the service

SAML flow

 

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 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

OAuth flow

 

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 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. If you happen to struggle with an omnichannel problem – deploying mobile apps and web applications, contact us now to hear how you can easily take benefit of both SAML and OAuth.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>