In short, they describe two different usage scenarios of OAuth involving two respectively three parties.

3-legged OAuth describes the scenario for which OAuth was originally developed: a resource owner wants to give a client access to a server without sharing his credentials (i.e. username/password). A typical example is a user (resource owner) who wants to give a third-party application (client) access to his Twitter account (server).

On a conceptual level it works in the following way:

• Client has signed up to the server and got his client credentials (also known as “consumer key and secret”) ahead of time
• User wants to give the client access to his protected resources on the server
• Client retrieves the temporary credentials (also known as “request token”) from the server
• Client redirects the resource owner to the server
• Resource owner grants the client access to his protected resources on the server
• Server redirects the user back to the client
• Client uses the temporary credentials to retrieve the token credentials (also known as “access token”) from the server
• Client uses the token credentials to access the protected resources on the server

2-legged OAuth, on the other hand, describes a typical client-server scenario, without any user involvement. An example for such a scenario could be a local Twitter client application accessing your Twitter account.

On a conceptual level 2-legged OAuth simply consists of the first and last steps of 3-legged OAuth:

• Client has signed up to the server and got his client credentials (also known as “consumer key and secret”)
• Client uses his client credentials (and empty token credentials) to access the protected resources on the server

Above I used Twitter as an example, though strictly speaking, they don’t use 2-legged OAuth, but a variant of it. They not only provide the client credentials but also the token credentials (see also Using one access token with OAuth).

As you have seen, 2-legged OAuth is nothing new, it is simply using OAuth in a different scenario than it was designed for. And hence you can use (almost?) all existing OAuth libraries for 2-legged OAuth, too.

First, there are some preparations necessary, namely the download of the required files:

• Get the OAuth component and place its content in “app/controllers/components”
• Get the OAuth library and put it in “vendors/OAuth”
• Set the security level in app/config/core.php to “low” (thanks to Bryan Young for mentioning in the comments)

The next step is to register your application at the service provider (e.g. Yahoo’s Fire Eagle) to get consumer key and consumer secret. Those values are then stored in a class called FireEagleConsumer if we go on using Fire Eagle as example service provider in this article:

// app/controllers/components/oauth_consumers/fire_eagle_consumer.php
class FireEagleConsumer extends AbstractConsumer {
    public function __construct() {
        parent::__construct('THE KEY', 'THE SECRET');
    }
}

This class is then used by the component to access consumer key and secret.

Using an OAuth-enabled API consists of four steps:

• Get RequestToken
• Authorize RequestToken
• Exchange RequestToken for AccessToken
• Access the API using the AccessToken

In the ideal case the first three steps are performed once. But it is also possible that for example the service provider expires the AccessToken after some time, and so those steps have to be repeated.

Anyway, let’s have a look at how those steps look in code. We start with getting the RequestToken:

// app/controller/oauth_consumer_example_controller.php
class OauthConsumerExampleController extends AppController {
    public $uses = array();
    public $components = array('OauthConsumer');
	
    public function index() {
        $requestToken = $this->OauthConsumer->getRequestToken('FireEagle', 'https://fireeagle.yahooapis.com/oauth/request_token');
        $this->Session->write('requestToken', $requestToken);
    }
}

The code is probably self-explanatory, we have to add the component to the $components array, and then we get the RequestToken from the specified url (while writing this I just realized it would make sense to move the url to the FireEagleConsumer class…).

The next step is simple: we have to redirect the user to the authorize page of the service provider:

// app/controller/oauth_consumer_example_controller.php
class OauthConsumerExampleController extends AppController {
    public $uses = array();
    public $components = array('OauthConsumer');
	
    public function index() {
        $requestToken = $this->OauthConsumer->getRequestToken('FireEagle', 'https://fireeagle.yahooapis.com/oauth/request_token');
        $this->Session->write('requestToken', $requestToken);
        $this->redirect('http://fireeagle.yahoo.net/oauth/authorize?oauth_token='.$requestToken->key);
    }
}

After the RequestToken is authorized, we get redirected to a callback url we specified while registering the application. We can now exchange the authorized RequestToken for an AccessToken:

// app/controller/oauth_consumer_example_controller.php
class OauthConsumerExampleController extends AppController {
    public $uses = array();
    public $components = array('OauthConsumer');

    ...

    public function callback() {
        $requestToken = $this->Session->read('requestToken');
        $accessToken = $this->OauthConsumer->getAccessToken('FireEagle', 'https://fireeagle.yahooapis.com/oauth/access_token', $requestToken);
    }
}

In a real use case you would also save the data of the AccessToken (key and secret) to the database, so you don’t have to perform all those steps every time you want to call the API.

The last step is to call the API, in this example to get the latest location of the user:

// app/controller/oauth_consumer_example_controller.php
class OauthConsumerExampleController extends AppController {
    public $uses = array();
    public $components = array('OauthConsumer');

    ...

    public function callback() {
        $requestToken = $this->Session->read('requestToken');
        $accessToken = $this->OauthConsumer->getAccessToken('FireEagle', 'https://fireeagle.yahooapis.com/oauth/access_token', $requestToken);
        $data = $this->OauthConsumer->get('FireEagle', $accessToken->key, $accessToken->secret, 'https://fireeagle.yahooapis.com/api/0.1/user');
        // do something with the data
    }
}

That’s it. Feedback is welcome!

Update 2008-09-15: Slightly adapted for new version of the component.
Update 2009-01-14: Adding hint about security level.

First the scenario for OpenID:

• User wants to access his account on example.com
• example.com (the “Relying Party” in OpenID lingo) asks the user for his OpenID
• User enters his OpenID
• example.com redirects the user to his OpenID provider
• User authenticates himself to the OpenID provider
• OpenID provider redirects the user back to example.com
• example.com allows the user to access his account

And now the scenario for OAuth:

• User is on example.com and wants to import his contacts from mycontacts.com
• example.com (the “Consumer” in OAuth lingo) redirects the user to mycontacts.com (the “Service Provider”)
• User authenticates himself to mycontacts.com (which can happen by using OpenID)
• mycontacts.com asks the user whether he wants to authorize example.com to access his contacts
• User makes his choice
• mycontacts.com redirects the user back to example.com
• example.com retrieves the contacts from mycontacts.com
• example.com informs the user that the import was successful

From those scenarios we can see that OpenID is about authentication (i.e. I can identify myself with an url) whereas OAuth is about authorization (i.e. I can grant permission to access my data on some website to another website, without providing this website the authentication information for the original website).

I hope this helps to keep apart those two standards :)