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.
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
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,
No comments:
Post a Comment