avatar

Derek Zeng

A programmer

2-legged vs. 3-legged OAuth

by coderek

Published on January 10, 2011, by cakebaker

From emails I receive it seems like there is a bit of confusion about what the terms 2-legged OAuth and 3-legged OAuth mean. I hope I can clear up this confusion with this article (and don’t contribute more to the confusion…).

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.

(End of article)