OAuth: Token-Based Authorization for the Social Networking Age
by Jaswinder Singh
March 4, 2010
The OAuth token-based authorization system allows users to grant third-party access to their resources without sharing their usernames and passwords. It's perfect for the age of social data scattered across many social networking sites.
Web users today have their social data (such as profiles, friends, photos, videos, messages, and so on) scattered across different social sites, and they want to access and use this data from outside these sites. This requirement poses a serious security challenge for you developers: how to enable users to access their private data in social sites without having to share their credentials.
Some type of API authorization mechanism would help overcome this challenge. This is where OAuth comes into the picture. OAuth is an open authorization protocol that allows standard and secure API authorization without exposing the user's credentials. It also provides a mechanism to grant limited access (in scope, duration, and so on). This article provides an overview of OAuth's token-based authorization system and explains how this system works between two web sites.
OAuth Overview
OAuth is an open protocol composed of different industry standard protocols (such as Google Auth Sub, AOL Open Auth, and Yahoo BB Auth) for standard and secure authorization. It was created by extracting the best practices and commonalities of each of these protocols, so that it easily could be implemented on and supported by existing services. A key area where OAuth is better than all the protocols on which it's based is its cross-platform capabilities. It offers built-in support for web browser, mobile phone, PDA, set-top box and desktop applications.
OAuth provides a method for users to grant third-party access to their resources without sharing their usernames and passwords. In other words, OAuth allows you to access the protected resources stored at one site from another site without exposing your credentials to the site you're accessing.
OAuth follows a token-based authorization system. The consumer exchanges the request token for an access token to get access to the user's protected resources stored on some service provider server. As an example, suppose a web user (User) came across a web site named PrintPhoto (Consumer), which can print photos stored anywhere on the web or a social network. The user has his/her holiday photos stored on a social network named MyPhoto (Service Provider). The user wants to print those photos but MyPhoto doesn't provide a printing service, so the user interacts with PrintPhoto to get his/her photos from MyPhoto and print them. PrintPhoto asks for his/her MyPhoto username and password to get the photos. Although the user wants to print the photos, he or she doesn't want to share these credentials because they are the same username and password he or she uses for his/her bank account. What to do?
OAuth to the rescue! It allows the user to grant access to one site (consumer) to access private resources stored at another site (service provider). If MyPhoto and PrintPhoto support OAuth for authorization, then the user could get his/her photos printed without sharing those credentials. Before walking through how OAuth handles the request, you should be familiar with a few terms:
User: Social network (Orkut, Facebook, Twitter, iGoogle, etc.) users like you and me
OAuth Provider: Web site or social networking site where the user's private resources are stored
OAuth Consumer: Web site, social networking site, mobile device, set-top box, etc. trying to access the protected resource on the other site
Now, let's see how OAuth handles user request to print your photos.
First Step: Registration Between PrintPhoto and MyPhoto
For PrintPhoto (OAuth Consumer) to add support for MyPhoto (OAuth Provider) it needs to register itself with MyPhoto and get the API key and secret. Both PrintPhoto and MyPhoto will store the generated API key and secret at their ends to use them for future requests (see Figure 1).
Second Step: User Request PrintPhoto to Get Data from MyPhoto
Now, when the user requests PrintPhoto (OAuth Consumer) to get his photos from MyPhoto (OAuth provider), PrintPhoto makes a new OAuth request to MyPhoto containing the API key and secret. MyPhoto generates a request token (unauthorized and not user-specific) and sends it back to PrintPhoto. When PrintPhoto gets the request token, it redirects the user to MyPhoto for authorization of the request token (see Figure 2).
MyPhoto (OAuth provider) first checks for user authentication. If the user is not logged in, it redirects him/her back to the login page. After the user logs in, MyPhoto redirects the user to the authorization page, which contains the information about the PrintPhoto request to access his/her private resources. The user can grant or deny the PrintPhoto request and revoke it at any time. When the user grants PrintPhoto access to access his account, MyPhoto marks the request token as user-authorized and redirects the user back to the PrintPhoto. After PrintPhoto receives the authorized request token, it gets it in exchange for an access token with MyPhoto and uses the access token for each request to access protected resources (see Figure 3). Request tokens are used only once to get the access token. After that, the consumer can use the access token to access user-protected resources.
Now, PrintPhoto uses the access token to make a request to MyPhoto for user photos. This time, PrintPhoto will get the access to user photos and the user can now select the photos to be printed. During this entire process, the user never shared his credentials with PrintPhoto, yet he got his photos printed.
Jaswinder Singh works as a Technology Analyst at SETLabs (the R&D wing of Infosys Technologies Ltd). He has experience in the developing Java and Java EE applications. Some of the key technologies he has worked with are Google Gadgets, Google App Engine, Software Factory, Eclipse Plugin Architecture, and Cloud Computing.
