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 .