I was going through some of the forums related to security concepts and found one topic which is very common. Many people have posted their confusions regarding the terms related to Authorization, Authentication, and Security protocols. So, I thought to write something about this in layman's terms, which is more towards the concept and less towards the technical aspects. Before we start, let's have a look at the question that really lit the spark in me - 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 what this article is.
What are Authentication and Authorization?
In simple terms, authentication is the process to verify whether the user is the intended user rather than any fake identity. On the other hand, authorization deals with accessing resources. Authorization tells which resources a user can access and to what extent. So, in most of the applications, both terms run hand-in-hand.
Single-Sign-On
SSO is an authentication mechanism in which a user can log in to one application using some sort of credentials and access another application without re-entering the credentials. In this scenario, the same credentials can be used to log in to another application. A 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 authenticate ourselves again and again to use other applications (apart from a few more secure apps).
- Benefits of going with SSO are quite pleasant
- A 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 purposes 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 figures will give you a 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 replying party, which is OpenID.
How is Authentication 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. After that, the request went to Google for account verification. On successful verification by Google, the user is redirected back to Blogger along with a token (we will discuss the token shortly. But at this point, you can imagine it as a label which tells Blogger that this user is verified by Google and Blogger can rely on him). From now on, Blogger trusts this token and initiates the session for the user.
OAuth2
OAuth is short for Open Authorization and is mainly used for accessing delegation via token-based authentication. Using this access delegation, an 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 Alan to stay and take care of your home. Of course, you have to hand over the keys to Alan. Which means Alen can enter the house and access the resources inside the house. In this analogy, home is the resource server, Alan is the client, the door lock is the identity provider and the house owner is the user. Makes sense?
Let’s change the thought process a bit. At present, until I’m back, Alan is occupying the home in my absence. Which means Alan 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. This 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 OpenIDConnect, 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 the 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 |
Extra information: Why do we need OpenId Connect?
By now, most of us are already aware that OAuth 2.0 is an authorization protocol and it really did a great job by providing information, which facilitated its user to take some prodigious authorization decisions.
But what about exchanging this information? How to do that? Is that exchange done in a secure manner? Blah blah blah…
All such sorts of questions are dealt with in different manners as every authentication provider has its own mean of exchanging this OAuth information. As not all the providers have provided an equivalent level of security, it led to some buzzes.
Here, OpenID Connect came to the rescue. It fixes all the common problems by providing an authentication protocol with a standardized way of exchanging messages between a provider and subscribers, which is nothing but a combination of OAuth and OpenID.
We will witness this by taking a coding example in one of my upcoming articles. Till then, stay tuned!!!