Understanding concepts - OpenId, OAuth and SAML

I was going through some of the forums related to security concepts and found one topic which is very much communal, and many people posted questions about their confusion on the terms related to Authorization, Authentication and Security protocols. 

So, I thought to write something about these terms in layman, which is more towards the concept and less towards technical aspects. 

Before we start, let's have a look at the question, which really lighten the spark in me - stackoverflow.com - What's the difference between OpenID and OAuth? Hope you are with me to get started.

Well, one of the major aims of any application is to make it secure and easy to use without imposing much work on the end user. Now, in order to fulfill this aim, we have to look into a few of the major security aspects in terms of protocols, usage and scenarios. And that's why this article is.

What is Authentication and Authorization?

In simple terms, authentication is the process to verify whether the user is the intended user rather than any fake identity. In fact, it is the same who it claims to be. Whereas authorization deals with accessing resources. Authorization tells which resources user can access and till how much extent. So, in most of the applications these both terms run hand-in-hand.

Single-Sign-On

SSO is an authentication mechanism in which user can log in to one application using some sort of credentials and accesses another application without re-entering the credentials. In this scenario, same credentials can be used to log in to another application. 

Best real-world example can be – our internal corporate portal in which we can find links of many other applications. So, once we are logged in to the portal, we need not to authenticate our self again and again to use other applications (apart from few more secure apps).

Benefits of going with SSO are quite pleasant as:

• User needs to remember only one set of credentials and the same can be used with other related applications
• Maintaining credentials in one place saves space as well as reducing cost.

How to implement this SSO?

Here come the security protocols, or say jargons like SAML, OAuth, OpenID, etc. Confused? Scratching your head? 

No need to worry. Sit back and relax. We do have ready made APIs to rescue us. 😊

Now before jumping straight into coding, let’s first get the gist of these jargons.

OpenID

OpenID is used for authentication purpose and allows us to use an existing account to log in to numerous sites. It was founded by a non-profit organization named as OpenID Foundation. Today this open standard is accepted by many giants like Microsoft, Google, Facebook, AOL, and many more.

How to get an OpenID account?

Getting an OpenID account is very simple as it can be obtained through any of the OpenId providers (as listed above). Once the account is obtained, the user can log in to any web site which supports OpenID authentication. 

As an example, you can imagine your blogger.com account accepting a google email id for authentication. In this example, Google is the Identity Provider and Blogger.com is the Relying Party. Below figure will you clear idea on what we just understood.

Please note that all this communication is happening because of the common trust factor between an identity provider and relying party, which is OpenID.

How Authentication is taking place?

Continuing with the same example of the blogger web site, the user hits the URL of Blogger.com and lands on the login page. There he enters his google credentials. Post that, request went to google for account verification. On successful verification by Google, the user is redirected back to the Blogger along with a token (we will discuss about the token shortly. But at this point, you can imagine it as a label which tells the blogger that this user is verified by google and blogger can rely on him). Hereon, Blogger trusts this token and initiates the session for the user.

OAuth2

OAuth is short for Open Authorization and is mainly used for access delegation via token-based authentication. Using this access delegation, application can access resources on the resource server on behalf of the user without the need of re-entering the credentials. This is achieved by using the tokens issued by an identity provider, with the user’s consent. 

Let’s understand this with an example, say you are going out of town and you want your friend Alen to stay and take care of your home. Of course, you have handover the keys to Alen. 

Which means Alen can enter the house and access the resources inside the house. In this analogy, home is the resource server, Alen is the client, door lock is the identity provider and I/house owner is the user. Makes sense?

Let’s change the thought process a bit. At present, until I’m back,  Alen is occupying home in my absence. Which means Alen is the owner of the house. Although it is for the time being but still Alen can be considered as an owner of the home. Such fable is termed as pseudo-authentication.

OpenID Connect

In order to implement a complete security solution, both OpenID and OAuth should go together. This togetherness is termed as OpenID Connect, wherein authentication is supported by OpenID and authorization is supported by OAuth2.

SAML

SAML is short for Security Markup Assertion Language and is an open standard for both authentication and authorization. It uses XML for all its transactions with a purpose of allowing identity providers to pass credentials to service providers. In most of the real-world scenarios, identity providers and service providers are totally separate entities. 

Now, for both to work on SSO mechanism, some sort of centralized user management is required and here comes in SAML assertions. There are three types of assertions:

• Authentication: Tells that user is authenticated at what time and by using what method
• Attribute: This is a piece of data which provides information about the user with some specific attributes
• Authorization: Tells that user is granted or denied the access of any resource

Summary

Here is the summarized view taken from Jaime's blog about what each one of these does.

Description	OAuth2	OpenId	SAML
Token (or assertion) format	JSON or SAML2	JSON	XML
Authorization?	Yes	No	Yes
Authentication?	Pseudo-authentication	Yes	Yes
Year created	2005	2006	2001
Current version	OAuth2	OpenID Connect	SAML 2.0
Transport	HTTP	HTTP GET and HTTP POST	HTTP Redirect (GET) binding, SAML SOAP binding, HTTP POST binding, and others
Security Risks	Phishing OAuth 2.0 does not support signature, encryption, channel binding, or client verification.  Instead, it relies completely on TLS for confidentiality.	Phishing Identity providers have a log of OpenID logins, making a compromised account a bigger privacy breach	XML Signature Wrapping to impersonate any user
Best suited for	API authorization	Single sign-on for consumer apps	Single sign-on for enterprise Note:  not well suited for mobile

Hope you enjoyed reading!