5 Jan 2018

SAML VS OAUTH

While some companies still use manual coding and pre-built adapters to provide access to systems, this often poses potential security issues. Application access through these methods allow unsecured and uncertified custom code, which could lead to a serious security flaw in the user’s network infrastructure. Identity and authentication, Single Sign-On (SSO) and secure API access are what outbreaks the developers. There enter SAML and OAuth. But as an enterprise organization, which one should you use? Which one is better?

In many cases, the answer to both of these questions may depend on the application and access needed. The bottom line is that both provide some comparable functionalities but they solve different problems. So, explore this article and look at some basic definitions of SAML and OAuth and their major differences.

SAML

The Security Assertion Mark-up Language (SAML), is an open standard that allows security authorizations to be shared by multiple computers across a network. It describes a framework that allows one computer to perform some security functions on behalf of one or more computers.

OAUTH

OAuth is an authorization protocol, in other words, a set of rules that allows a third-party website or application to access the user’s data without the user needing to share login credentials.

OAuth’s open-source protocol enables the users to share their data and resources stored on one site with another site under a secure authorization scheme based on a token-based authorization mechanism.

THE SAML WORKFLOW

• An end user clicks on the “Login” button on a file sharing service. The file sharing service is the Service Provider, and the end user is the Client.
• To authenticate the user, it 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 validates 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, which also includes the user identity 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 the client in to the service.

SAML 2.0 FLOW

THE OAUTH WORKFLOW

OAuth does not assume that the Client is a web browser.

The example workflow proceeds as follows:

• An end user clicks on the “Login” button on a file sharing service. The file sharing service 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 to 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 is valid, the Authorisation Server sends information about the Client to the Resource Server.

OAUTH 2.0 FLOW

THE OTHER DIFFERENCES

TOKEN OR MESSAGE FORMAT

• SAML deals with XML as the data construct or token format.
• OAuth tokens can be binary.

TRANSPORT

• SAML has Bindings that use HTTP such as HTTP POST Binding, HTTP REDIRECT Binding etc.
• But there is no restriction on the transport format. The client can use SOAP or JMS or any transport they want to send SAML tokens or messages.
• OAuth uses HTTP exclusively.

SCOPE

• Even though SAML was designed to be applicable openly, it is typically used in Enterprise SSO set-ups:
• Within an enterprise or
• Enterprise to partner or
• Enterprise to cloud scenarios.
• OAuth has been designed for the use with applications on the internet, primarily for delegated authorization of internet resources. OAuth is designed for Internet Scale.