Introduction to OAuth – Part 2

In this blog we will discuss how OAuth works. Our focus would be on OAuth 2.0. There are many articles on the internet that talks about OAuth 1.0.


How OAuth 2.0 is different from OAuth 1.0

OAuth 1.0 involved certificates so if you were to code for OAuth 1.0 you would have to know about how to sign the requests using signature methods like HMAC-SHA1 or RSA-SHA1 etc. OAuth 2.0 is much simpler. It relies on SSL instead of signatures.

OAuth 1.0 had only one flow for authentication. OAuth 2.0 defines multiple flows or client profiles for handling authentication e.g. web application, user agent and native.

Actors in OAuth 2.0

Following are the important roles in OAuth 2.0

a. Resource Owner – Person whose data/information is to be shared between two applications.

b. Resource Server – Application that hosts user’s data/information.

c. Client Application – Application that needs to access data from the resource server on the resource owner’s behalf.

e.g. let’s assume that I want to use friendfeed to browse the photos that I have uploaded to my Flickr account. In this case, I become a resource owner, Flickr becomes a Resource Server and FriendFeed becomes a Client Application.



Getting Ready for OAuth

Before a client application can start accessing resources on the resource server, it needs to register itself with resource server. This registration is a one time activity and once registered client application gets a client id and secret.

During registration, client application also provides a redirect uri to resource server. This redirect url is used during the OAuth authorization flow.

In the above example, FriendFeed would have registered it with Flickr and obtained client id and secret from Flickr.



OAuth authorization flow

Let’s look at Oauth authorization flow for a web application profile.

Continuing with the above example, assume that I am trying to use firendfeed to access my photos that I have uploaded to my Flickr account. At this time FriendFeed will check if it has an access token in order to get photos from Flickr on my behalf. If access token is not found then FriendFeed would initiate OAuth flow which would typically have following steps.

Step 1: User accesses client application.

Step 2: Client application redirects to resource servers authentication page.

Step 3: Resource server authenticates the user and then obtains user's authorization for the data that client application is trying to obtain from the resource server on the user's behalf.

Step 4: The Resource server generates the authorization code and redirects to client application including authentication code. Resource server uses the redirect url that client application provided during registration.

Step 5: Client application sends a request for access token. Client application includes the client id and secret in this request.

Step 6: The Resource server sends the access token. This access token comes with an expiry date.

Step 7: The Client application accesses the services provided by the resource server to access user’s data as long as access token is not expired.



Here we looked at the flow for web application profile. The flow would vary slightly for other profiles.

Introduction to OAuth - Part One

In my last blog, I talked about OpenID which solves the problem of one having to remember userid and password for multiple websites. Today I will talk about another problem related to passwords.


In today’s world, a lot of our personal information is scattered across multiple websites and many a times you would like all this information to be consolidated at one place e.g. your financial information may be scattered across the websites of multiple banks. We also have lots of social networking sites today and here also we typically use different sites to share different types of information. E.g. instagram to share photos, tripit to share travel plans. Generally what you share in one social networking site is available to others in the same network but most likely you would like this to be available to users of other sites as well. E.g. you would like your instagram photos or your tweets are available to your facebook friends as well.

Now a day’s most of the popular websites provide services and APIs. Websites and applications can use these services and APIs to access and display user’s information from multiple different websites.

If a website or an application needs to pull the user’s data from multiple websites then it would need to store user credentials (userid/password) for all such websites and use them to pull information on the user’s behalf. The Problem with this approach is that not many user’s would be comfortable in sharing their credentials and rightly so.

OAuth is an open protocol that allows websites and applications to securely expose and consume services and APIs. It solves the problem of how one website can access user’s data/information from another website without knowing the user’s credentials.

In my next blog I will get deeper into how OAuth works.