How OAuth Differs from SAML and OpenID

OAuth - An Overview 

Open Authorization or OAuth 2.0, as we all call it, is an authorization framework that provides detailed guidelines to grant or control protected access to various kinds of digital assets. It’s effortlessly applicable on APIs, hardware, apps, users, systems, and even servers. 

The access is controlled by an access token and application/API/devices are permitted to deny access if allotted or pre-defined token information isn’t provided or wrongly entered.

Before OAuth (2010), HTTP’s basic method was used for access control, but things changed for good. The current version, OAuth 2.0, came into effect in 2012 when REC 6749 update reformed primitive OAuth 1.0 extensively.

Have a look at the key characteristics of OAuth:

• Its performance is at par when used on mobile as it’s based on JSON
• Keep in mind that OAuth only deals in the authorization; not in the identity-confirmation. Hence, if latter is your aim, try to club OAuth with verified authentication means.
• As it lacks authentication, its large-scale usage isn’t recommended.
• It’s ideal for cutting-edge web as it supports API calls.
• The entire authenticity of OAuth is based on the relationship that the server and client share.
• It uses tokens for access control instead of conventional passwords.

How it works?

As far as OAuth processing is concerned, one must understand that it’s majorly based on three factors or components; consumer, end-user & service partner/provider.

1. The procedure starts when any user shows interest in using a service, e.g., a Twitter user wishes to post a tweet on the platform.
2. The consumer service, on person’s behalf, will ask for a unique token from the Social Media giant in this case. 
3. The token remains a confidential for both parties.
4. Consumer will forward it to the end-user and ask him to use it on the SM platform.
5. When the end-user will log into his SM account, the consumer will forward the related request to SM platform.
6. The platform can accept or reject the request as per the credibility of the token received. 
7. The permission is granted to the service in question (i.e., consumer), and not to the end-user directly.

Now, you must understand that the tokens used in OAuth are of two kinds: Ones with short lifespan and the ones with longer lifetime.

Both the token types are encrypted to keep the data protected.

‍

SAML - An Overview 

After having clarity on OAuth, it’s time to move to SAML which stands for Security Assertion Markup Language. It was designed by the OASIS Security Services Technical Committee in 2002. If the history of protocols is taken into consideration, it’s easy to conclude that SAML is indeed the oldest option that we’ve had.

Functionality-wise, SAML is a globally recognized open standard that must be followed for exchanging the credentials for authentication and authorization. Here, the parties involved are service-givers and identity providers in general.

After its conception in 2002, it has gone through multiple updates and reformations. Presently, SAML 2.0 is preferred and adopted the most. 

How it works?

The key roles that exist in SAML working are:

1. The subject is most commonly the humans who wish to use a cloud-based tool/application.
2. IdP or identity provider is the term used for the cloud-based software that saves identity data of users. It is easily accessible via a simple login process. IdP is responsible to affirm that the person trying to access the cloud application is allowed to do so.
3. Lastly, the service provider or service-giver is that cloud-hosted tool/application that the end-user is trying to access. Gmail, Outbox, Microsoft 365, and Google Photos are some of the most commonly used service providers. In general, people can enter into these applications directly. But, when SSO is implemented, SAML will control the access and decide which access request should be processed and which to be denied.

All these three components work together when SAML is implemented. 

• Principle raises an access request that reaches the service-giver
• Upon request’s receipt, the provider looks for the user’s data in IdP through another request.
• IdP shares the SAML assertion - a message informing the service-giver about a user login event. It may include critical user identity details. Based on the SAML received, subject’s request is processed.

‍

OpenID - An Overview 

It is a distinct user identification process used in the SSO technique to control multi-site access. The protocol’s key focus is on making things easy to process and less complicated so that end-user identity-checking is possible for everyone.

OpenID is an OAuth 2.0-based authentication open standard. It eliminates the need of having multiple user accounts for different websites.

Generating and managing different login accounts leads to errors and confusion. It’s not easy to generate a strong password for diverse websites and manage them as well. 

With OpenID, it’s possible to log in to multiple websites with a single ID. It is intended to continue with the identity-check based on what’s gathered by the Authorization Server. Hence, it’s easy to conclude that its implementation isn’t possible without OAuth. With its help, it’s easy to learn about the end-user information by exposing it to the REST API.

How it works?

OpenID permits the user to proffer evidence if s/he owns a particular URL that can be used for credential authentication. Using the URL, it’s easy to prove user’s authority is as it acts like an credibility-verifier.

As far as authentication is concerned, it can be done in multiple ways.

Most commonly, the website captures the URL to find out the whereabouts of the OpenID provider. Once that’s done, it takes the help of Diffie- Hellman key exchange to create a secret with the OpenID provider. This is done to make sure that the OpenID provider is able to sign the message b/w OpenID provider & user. 

For first-time OpenID users, sign-in is possible via the OpenID provider only. After that, the end-user is redirected to a trusted website using the assertion. The assertion is related to the authentication approval.

‍

SAML vs OAuth

Though both are part of the Single Sign On strategy, they stand miles away from each other regarding similarities. They differ from each other on various fronts.

For instance, message transmission in SAML is done using XML while OAuth uses JSON for the same job. OAuth is mobile-based and simple to use. Its large-scale usage isn’t promoted. SAML is fit for enterprise security as it’s extensive and widespread. For the same reasons, it’s complex.

As OAuth is capable of working with API calls perfectly, it’s preferred for mobiles, gaming consoles, IoT, and the modern web as all these devices are API-based. SAML has limited implementation because of its ability to leave a session cookie in the browser. It’s only preferred to authenticate people/users for short-lived work days.

‍

SAML vs OAuth vs OpenID - Main differences

Let’s break this discussion into 2 parts to simplify the subject for you:

OpenID vs OAuth

• OpenID deals in authentication while confirming/providing the authority is the key focus of OAuth. 
• The main concerned area of OpenID is federated authentication which deals with allowing 3rd party tools for user authentication. OAuth works oppositely. It’s designed to eliminate the need of sharing or creating a password for various 3rd party applications.
• OpenID was created for 3rd party apps and APIs specifically while OAuth is for eliminating the use of login passwords with others as these details/credentials might be compromised.
• The openID utilizes identity assertion to operate. OAuth is generic. 

SAML vs OAuth

SAML vs OAuth is an extensive topic. The notable differences are:

• SAML can authorize as well as authenticate. OAuth does authorization only. 
• SAML is strongly encryption-backed; OAuth is weak due to encryption’s absence. 
• Both are token-based, but their tokens are known by different names. The SAML token is known as SAML assertion while OAuth tokens are known as access tokens. 

‍

Which of the three protocols to use and when?

It’s important to find out about the use cases of these three protocols. SAML is suitable for identity management as its strong encryption can keep crucial information safe. Virtual desktop infrastructure is also a notable SAML application. 

OAuth is suggested when you need to enforce security practices for mobile applications, at least possible hassle.

Try OpenID when an application requires temporary access. OpenID is useful when all the authentication work has to be done by you.

Ending Notes

The world of IT security is extensive and Single Sign On is one part of this far-reaching concept. SAML, OAuth, and OpenID are three main techniques that are used widely in SSO. But, they are highly diverse in their functioning. This blog is useful to understand the key differences between SAML vs OAuth vs OAuth. Having better clarity will lead to upright implementation.