SAML vs OAuth: Know the Difference Between Them

Single sign-on (SSO) has evolved quietly into federated authentication. Federated authentication streamlines user login credentials across multiple platforms and applications to simplify the sign-in process while enhancing security.

Security Assertion Markup Language (SAML) and Open Authorization (OAuth) have emerged as the go-to technologies for federated authentication. While SAML is an Extensible Markup Language (XML)-based standard, OAuth is based on JavaScript Object Notation (JSON), binary, or even SAML formats.

OAuth Overview

OAuth is an open standard protocol that generates authorization tokens that validate an application (also called a client) to access restricted resources from the service provider. OAuth launched in 2006 as part of Twitter’s OpenID implementation protocol. It has two main versions: OAuth 1.0 and OAuth 2.0.

OAuth 1.0 launched in 2010 and uses the Hash-based Message Authentication Code-Secure Hash Algorithm (HMAC-SHA) signature strings, while OAuth 2.0—the current standard—began in 2012. While OAuth 2.0 is built on top of OAuth 1.0 and shares the same overall user experience and goals, it is not backward compatible with version 1.0.

As an authorization protocol, OAuth 2.0, henceforth called OAuth, defines four roles:

Resource Owner. A Resource Owner is any user who authorizes a website or an application to access his/her account. Note that the application can only access restricted services.

Client. A Client is an application that wants to access the Resource Owner’s account on the Resource Server.

Resource Server. The Resource Server hosts protected user resources.

Authorization Server. The Authorization Server verifies the identity of Resource Owners and then issues access tokens to the Client.

The communication flow takes the following format:

Figure 1. The OAuth process flow

Here’s is a brief explanation of the process flow shown in figure 1:

The Client requests the Resource Owner to access a protected resource from the Resource Server.
The Resource Owner grants the request and issues an authorization token to the Client.
The Client (using the authorization token received from the Resource Owner and its own identity) requests an access token from an Authorization Server Application Programming Interface (API).
The Authorization Server authenticates the Client identity and in turn, issues an access token to the Client.
The Client, using the access token, requests the resource from the Resource Server.
The Resource Server serves the protected resource to the Client provided the access token is valid.

SAML Overview

SAML is an XML-based standard that interfaces identity providers with service providers. SAML tokens are essentially XML-based assertions that pass information about a resource owner (end-user) between an Identity Provider and a Service Provider.

SAML launched in 2002 as an open standard for exchanging authentication and authorization data in XML format. Since its launch, SAML has undergone one minor and one major update after its flagship version (SAML 1.0). In 2003, the Organization for the Advancement of Structured Information Standards (OASIS) consortium approved SAML 1.1. The current standard (SAML 2.0), which launched in 2005, has no backward compatibility with SAML 1.1.

SAML 2.0, henceforth called SAML, implements a secure system that helps authenticate and authorize XML-based tokens (also called security assertions) between the providers. There are two providers: an Identity Provider (IdP) and a Service Provider (SP). An IdP is an organization such as Microsoft Active Directory that undertakes the authentication process and sends the data to the SP alongside users’ access rights for the service.

On the other hand, an SP is an organization that requests the IdP to grant authorization to users. Consider a user who logs into any SAML-activated system such as SalesForce. SalesForce, which in this case is an SP, requests authorization from the appropriate IdP such as Microsoft Active Directory.

The SAML protocol passes information about users’ login credentials and other attributes between an IdP and an SP. Each user logs in just once to the SSO SAML-enabled system on the IdP. The IdP can then pass the SAML attributes in XML format to the SP when such a user attempts to access those services in the future.

The SAML workflow comprises of the following steps:

1. An end user clicks the Login button on the file-sharing service at an example website. The example website is the SP and the end user is the client.

2. The SP constructs a SAML authentication request, signs the request, encrypts it and sends it to IdP directly.

3. The SP redirects the client’s browser to IdP for authentication purposes.

4. IdP verifies SAML authentication request. If the request is valid, it presents a login form so the end user can enter his username and password.

5. After the client successfully logs in, IdP generates a SAML Assertion or Token which serves as the user’s identity, and sends it to SP.

6. IdP redirects Client back to SP.

7. SP verifies SAML Assertion, extracts user identity, assigns correct permissions to Client, and logs user to the service.

SAML Vs. OAuth: What is the Difference?

In the context of access management, authentication is the process of confirming a user’s identity while authorization is the process of determining the access privileges of an already authenticated user. Thus, authentication is concerned with user identity whereas authorization is concerned with user privileges.

While there are similarities between SAML and OAuth, the two protocols play different roles in access management, with SAML being used in authentication and OAuth in authorization.

SAML Is used to centrally manage users. When you log on to your office computer and network, you are using SAML. Users only need to enter their passwords once to get access to the network. However, for setting user privileges in the applications and services within the network, you need to use OAuth.

OAuth is also used to give you the ability to access one service from another without entering your logon credentials again. OAuth does this by letting you use your credentials in one service for the other service. If you’ve used your Gmail address to log on to Office.com, you are using OAuth.

OAuth saves you the trouble of setting and remembering different logon credentials for applications and services. It also helps save you time, since you do not need to enter your logon credentials when you need to access these systems.

SAML and OAuth complement each other. You can use the two protocols at the same time by letting SAML grant access to an application and using OAuth to allow access to a protected resource. You can also use an identity provider or single sign-on (SSO) service with either protocol or a combination of both.

Can you use both SAML and OAuth?

Yes, you can.

The Client can get a SAML assertion from the IdP and request the Authorization Server to grant access to the Resource Server. The Authorization Server can then verify the identity of the user and pass back an OAuth token in the HTTP header to access the protected resource.

Parallels RAS: SAML Single Sign-on Authentication

A well-thought-out and well-executed SSO authentication can mitigate the risks of insider threats and eliminate password-related downtime and costs. Moreover, it can help improve authentication and overall user experience while placing your organization firmly in the control of employee access.

Parallels® Remote Application Server (RAS) supports SAML authentication, allowing IT managers to streamline user access to published applications. As an inclusive VDI solution, Parallels RAS delivers centralized management via a single pane of glass. IT managers can deploy their workloads to on-premises, hybrid, public, and multi-cloud environments, all while leveraging the scalability of Parallels RAS’s cloud automation and SAML authentication.

By leveraging SAML authentication, Parallels RAS minimizes operational and administration overhead due to reduced user identity management. And since users log in using the same SSO credentials, their overall experience improves.

Download your 30-day Parallels RAS trial today and experience the power of SAML Single Sign-on Authentication.