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.

Introduction to OpenID

When was the last time that you wanted to access the website but you didn’t remember the user name or password? All of us face this situation quite frequently and people have come up with solutions which are quite risky from a security perspective. Some people use the same username and password across all websites. Others keep a note of username and passwords used in different websites.

Another annoying part is filling up the sign up form. Every time you register for a new website, you end up filing pretty much same information again and again.

OpenId is meant to solve these problems. The idea here is to create an id with an openId provider and use that ID to log on to sites that support openId. In an ideal world where all websites support openId you will end up having just one user id and password. Isn’t this amazing!

In terms of adoption, OpenID is used by many large websites including Facebook. If you are using services like Yahoo, Google, Flickr or Myspace, you already have your own OpenID. Additionally there are some dedicated ID provider like myOpenID, verisign and myID.net. Visit http://openid.net/get-an-openid/ for complete list.

Typical actors in OpenId standard are “id provider” and the “relying party”. This standard provides the framework for the two actors to communicate.

Coming to the problem of re-typing the same information again and again, OpenID standard has an extension (OpenID attribute exchange) that allows for transfer of user information from id provider to the relying party. This way you don’t need to retype this information all over every time you sign up to a new website.

OpenID is not free of all evils though. You need to be careful with your OpenID because if your OpenID and password is stolen then all your registered sites become a target! You would be better off if your OpenID service provider supports two factor authentication. VeriSign is one such provider.