What is OAuth ???

Hi All,

I came across a nice post on OAuth so couldn’t stop myself sharing this with you all.

Here is a long description which needs patience to read J , Hope you will like this :

Before I go straight to the definition of OAUTH and its elaboration, let’s talk about few things we already know to set the context. Also, my discussion on OAuth below is very generic and is not specific to SharePoint now. Once we are clear of OAuth concepts, we will see on SharePoint OAuth implementation in another upcoming post.

Apps: We all know what Apps are by now. The word App is so common now a days that I hope to see the nursery books replacingA for Apple  with A for Apps   Well, at least for me A is for Apps.

Service: We all understand the idea of Service. A Service can be a Web Service or API that is consumed by client applications

Service consumer : Any application that consumes a service. Now tell me what’s is the most common breed of application now-a-days that consume the Services?….guess… APPs! Yes, Apps are the most common Service Consumers now-a-days.

Service Provider: It’s the one who hosts the service and where the service runs. The service generally requires authentication so that only trusted consumers can access the restricted functionality or data offered by the service.

Now,  imagine as a developer, you have developed an enterprise application that offer users to play some interesting games on their Mobile devices. For that, you created a Windows 8 or iOS App (or any App) whose main function is to entertain user via some puzzle games on his mobile device.

Now, a new requirement is to allow the user to share the score on his Facebook timeline via your App.

               How can you make your App share the information on Facebook on behalf of User?

Isn’t it a most common and necessary requirement now-a-days? It is.

You will need to access the Service provided by Facebook (Service Provider) and authenticate your App to post on behalf of the User. An obvious solution is to ask User to provide his Facebook credentials and store it securely with you (in your DB\config or whatever). Now, whenever the user wants to share his score, your App will use the stored credentials and post on the Facebook wall on behalf of user.

With this (bad) solution, below uncomfortable questions arise around Security, Maintenance, and User Experience.

1. Security: Is it good to ask User for his Facebook credentials and store them with your application?
Although a user may enjoy playing with your App but he will most likely hesitate to provide you what you are asking. Of course, he cannot simply trust you!

2. Maintenance: What if you want to provide the same functionality with other social platforms like Twitter, LinkedIn or Yammer? Also, it will be difficult to maintain the user credentials for all the platforms you have integrated and also keep them in sync in case the User updates his account at Facebook, Twitter, and Yammer etc.

3. User Experience: If your App makes a User feel insecure about his social accounts, he will simply abandon your App. How can you prevent it? One solution is that instead of storing credentials, you can also present a login page when he can supply credentials. However, if your App connects with many Service Providers (Facebook, Twitter, LinkedIn, Yammer and many more upcoming) and you keep on asking the credentials every time, the user will not feel your App is really integrated . Isn’t it?

The solution to all above questions is OAUTH - an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.

OAUTH

OAuth is a standard way for Service providers and Consumers(Apps for example) to handle authentication. Also, the OAuth authorization framework enables a third-party application to obtain limited access to a service hosted by Service provider. By using OAuth, you can allow the user to access a service (Facebook wall for example) stored at one site(Service Provider) with another application without having to store or manage credentials at the Application side.

There are 3 main Actors in an OAuth transaction: the User, the Service Consumer ( which is generally an APP), and the Service Provider.  This gang of three are often said to form the OAuth Love Triangle.

  

Now, assuming that your Game APP implemented OAuth for FaceBook, it can initiate authentication using OAuth.

Below are the steps(and the technical conversation) that will occur at high level  among all parties:

1.  A user wants Service Consumer (App) to access his protected resource lying with Service Provider (Facebook) :

User: “Hey App, I enjoyed the game but now I would like you to be able to share my game score on my Facebook timeline.”

Game App: “No problem! Let me ask for permission from Facebook. ”

2.  The service consumer asks for request token from service provider.

Game App: “My user wants me to post to his wall. Please share a request token.”

Facebook: “Your request is answered. Take the token and associated secret.”

Using the secret,  the service provider is able to verify the future requests by consumer (if its coming from the valid Service Consumer).

3.  The user is redirected to the service provider where user approve the service consumer to act on his behalf.

Game App: “Hey user,  I’m redirecting you to Facebook so you can approve me for the actions you want. Take the token with you which I got  from Service Provider(Facebook).”

User: “Ok”

4.   The user sees a form presented by the Service provider which lists all the actions the Service Consumer can take on user’s behalf. If user thinks its all OK, he approves.

Facebook: “Welcome User, do you want to authorize the Game App for all the A, B, and C actions?”

 User: “Yes, I approve”

Facebook: “OK, the request token is approved for the Game App”

5.   The service consumer obtains an access token in lieu of request token from service provider

Game App: “Facebook, Can you provide an access token for this approved request token?”

Facebook: “Sure. Take the access token and secret.”

6.  The service consumer preserve the access token and secret information for later use.This information can be saved along with user account with service consumer.

Game App : Hey User, now you can share the score on your wall as long as you keep me authorized with Facebook.

User: Great! But please note I will revoke your permission on my account with Facebook anytime I wish.

7.   The service consumer accesses the protected resource (of user) on behalf of user.

 Game App: “My user wants to share score on his Facebook wall.  Here is the access token for the action”

 Facebook: “Your access token looks valid. Your request can be carried on!”

OAuth is adopted by many Service Providers like Facebook, Twitter,Google, Yahoo and all the Consumers that consume the service from them.

The initial version of OAuth is 1.0 which is  still being used by some software companies. The second and latest version , OAuth 2.0, is created to simplify development while still providing app authentication and specific authorization flows for web apps, desktop applications, and mobile devices. For OAuth history and deep details, you can go to oauth.net and Wikipedia .