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.
Use case type
Standard to use
|Access to applications from a portal||SAML|
|Centralised identity source||SAML|
|Mobile use cases||OAuth (preferably with Bearer Tokens)|
|Permanent or temporary access to resources such as accounts, files||OAuth|
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
|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|
The SAML workflow
- 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.
- To authenticate the user, example.com constructs a SAML Authentication Request, signs and optionally encrypts it, and sends it directly to the IdP.
- The Service Provider redirects the Client’s browser to the IdP for authentication.
- 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.
- 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.
- The IdP redirects the Client back to the Service Provider
- 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
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.
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:
- 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.
- The Resource Server presents the Client with an Authorisation Grant, and redirects the Client to the Authorisation Server
- The Client requests an Access Token from the Authorisation Server using the Authorisation Grant Code
- 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
- 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
- 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 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.
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
- 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.
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 and 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.