Programming Social Applications

Two-Legged Versus Three-Legged OAuth

We’ve already explored the standard, three-legged (application, provider, user) method for using OAuth 1.0a, stepping through the token-exchange workflow to gain an access token. Although this is how OAuth was originally intended to be used, some providers employ another method, two-legged OAuth, to allow application developers to collect private data with aggregated sources such as firehose feeds.

The implementation of two-legged OAuth mimics typical client-server communication relationships and removes the need to involve users in the process. This is a good way for providers to allow applications to access data on their systems while being able to track the amount of data that the application is requesting, mostly for rate-limiting and abuse-prevention purposes.

Note

A good way to think about two-legged OAuth is as the first and last steps of the three-legged OAuth process (getting the request token and exchanging that for an access token), eliminating the middle pieces in which the user authorizes the application.

The workflow for the two-legged OAuth process is:

1. The application owner creates a new OAuth application on the provider site to obtain a consumer key and secret.

2. The application will make requests to the provider site to access private data.

This process is much easier, but doesn’t fulfill the need for an intermediary user authorization step when you’re requesting privileged user information.

Now let’s take a look at a practical example ...