Two greatest and most important things that happened in Computer Science after World Wide Web 2.0 are the Advanced Distributed Systems aka Cloud Computing and the Big Data.
The current computing business is all about specialised services and from there only concepts like SaaS, PaaS and IaaS in the Cloud Computing world came out. One extremely important thing that empowers these various systems to talk with each other is the Application Programming Interface on the Web also known as Web Services.
Modern Web APIs rule the world because they enable a system to easily expose its services to other systems. Imagine a world where you have to develop a system that has its own geolocation and map generation code along with its own SMS and email implementation.
Now imagine a Force.com system that simply cannot talk with other Enterprise leaders like SAP and Oracle or any other legacy systems developed on a Java or .Net framework. It would simply be a nightmare!
With all these systems sharing and exposing data to each other on a very open network ie. Internet or a World Wide Web in general, they do need some secure way to authenticate and authorize and that’s when things like Oauth 2.0 came in.
Oauth 2.0 is one of the foremost protocols which have been designed considering the implementer’s convenience in mind, and thus all the leading API providers like Facebook, Twitter, Linkedin, Google, Salesforce, Github etc. have deployed their OAuth 2.0 servers long back. One thing that always haunts and tough for the beginners to understand is how this protocol works and why it is there and what is the reason for its popularity.
I will try to focus on answering these three questions:
Reason for popularity
It is one of the most flexible protocols to implement. A protocol is nothing more than a set of rules. OAuth 2.0 has many implementation ways or rules based on the use case and thus it is extremely adaptable. It has implementation patterns for all the three most common type of applications now a days 1. Web Server Based 2. Internet Client (Browser) based and 3. Mobile Based.
Why Oauth and How it works: I would like to draw an analogy here. Imagine you are a big corporate. You and your employees often travel to one of your most important business locations though none of your employees stay there permanently. You went ahead and bought a huge mansion having a dozen of rooms for them to stay whenever they are there. After buying it, in a couple of months you started realizing that the cost of maintenance for such a big mansion is as huge as your mansion and at the same time you realized that it is only during the peak season of your business this big house is fully occupied. After a year of analysis you realized that there are times when no one is using it, but still it needs maintenance and thus the money. One of you employee came up with a brilliant idea of renting its rooms to other small corporates at a competitive price. Thus, you will be able to pay-off your maintenance bills with it and might earn as well. This is very similar to the way Amazon first started renting its servers.
Think of the challenges you are going to face in this kind of set up.
One is there might be some groups in that area who would sign an agreement with you for a specific period and then they start re-renting it to others. I would like to call it the challenge related to Authentication that whether it is the right person who is going to use your mansion and its services or not. The other challenge is that there might be a chance that these guys would start using other rooms as well which they should not be or there might be situation when more guys would start staying in a room than its capacity. I would like to call it the problem of authorization ie. accessing things which one is not supposed to.
There are multiple ways to handle this. How in a typical Oauth 2.0 world, you are going to handle this I am explaining here in the steps below:
First, you hire a guy or a team of guys who would be responsible for all such security checks. These guys can understand the way they have to work is equivalent to an OAuth server code implementation.
Step 1: Signing a contract with the firm with all the details like number of rooms, tenure, number of people along with their identity proofs, etc. This is equivalent to creating an Oauth App at the services provider end.
Step 2: Once the firm signs up the contract for each of its employee, who is going to stay in the mansion would get a code, which they have to tell to the guys (call them your OAuth 2.0 security experts) that you hired. This is equivalent of getting Customer ID and a Customer Key.
Step 3: Once these employees reach there, they first have to show their identity cards etc., which these security experts will use to authenticate that these are the employees that are meant to stay as you have already shared their identity data with these experts. Think it of more as a Biometric Authentication system. While signing the contract with the firm, you asked the firm to ask its employees to carry and show the same identity proof that they have submitted at your end or you might have collected their Biometrics data and fed into your mansion’s Biometric system. This is like passing your username and password for authentication. At the same time, these experts will ask these employees to sign for certain things that they have to follow while staying there.
Step 4: Then these experts will ask for the Customer Key and the Code from these guys which are very specific to each employee and will provide them a key card for the room which is valid for a specific period. This key is equivalent to an OAuth token.
After that period if they want to re-enter in the same room, they have to go through step 3 and 4 again. This simply removes the chance of any authentication and authorization threat to your mansion.
At a very high level, this is how exactly OAuth 2.0 works. I hope now you can understand why you need a security mechanism for Authentication and Authorization for your Web Services implementation (which is the Mansion in my analogy) and how it works. In my next post, I will write about some of the ways on how Force.com implemented the Oauth 2.0 at their end, and I hope then this piece would make more sense to the technical folks.
