A Primer to the OAuth Protocol

OAuth uses digital signatures rather than the “Basic” authentication method used by the HTTP protocol.

The Service Provider checks the signature of the request and replies with an unauthorized request token:


The Consumer redirects Jane's browser to the Service Provider User Authorization URL:


If Jane is logged in to photosharingexample.com, this page will ask her whether she authorizes photoprintingexample.com to have access to her account. If Jane authorizes the request, her browser will be redirected back to http://photoprintingexample.com/request_token_ready?oauth_token=hh5s93j4hdidpola, telling the consumer that the request token has been authorized. The Consumer then will exchange the Request Token for an Access Token using the following address:


which will return the Access Token in the response:


This exchange will happen only the first time Jane tries to access her photosharingexample.com photos from photoprintingexample.com. Any time afterward, only the following will happen.

Now, the Consumer is equipped properly to access Jane's photos. First, the Consumer needs to generate the request signature. The initial step is to create the Signature Base String. This is a combination of the following elements:

oauth_consumer_key: dpf43f3p2l4k3l03
oauth_token: nnch734d00sl2jdk
oauth_signature_method: HMAC-SHA1
oauth_timestamp: 1191242096
oauth_nonce: kllo9940pd9333jh
oauth_version: 1.0
file: family.jpg
size: original

Ultimately, you end up with the string:


If your request is being transmitted through SSL, the request can be in plain text. However, a vast majority of Web sites do not use SSL, so the signature string must be encoded.

Traditionally, the HTTP protocol uses an authentication method it calls “Basic” in which users provide their user names and passwords in order to gain access to the protected resource. The major flaw in that procedure is that those credentials are passed in plain text, clear for any people listening to read and store as they wish. In order to protect users' credentials, OAuth uses digital signatures instead of sending credentials with each request.

This digital signature is used to verify that the request being made is legitimate and hasn't been tampered with. A hashing algorithm is used to make that work. In order to allow the recipient to verify that the request came from the claimed sender, the hash algorithm is combined with a shared secret. If both sides agree on a secret known only to both parties, they can add it to the content being hashed. This can be done by simply appending the secret to the content, or by using a more sophisticated algorithm with a built-in mechanism for secrets, such as HMAC.

For this example, let's say the Service Provider allows HMAC-SHA1 signatures. Thus, the encoded signature string becomes:


All together, the Consumer request for the photo is:


The Service Provider performs the same work flow to calculate the signature of the request that the Consumer performs. It then compares its calculated signature to the provided signature. If the two match, the recipient can be confident that the request has not been modified in transit. The Service Provider then responds with the requested pictures.

This process can be daunting to deal with programmatically. There are a number of libraries written for both the OAuth server and client for quite a few programming languages.


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState