2-legged vs. 3-legged OAuth

Posted: January 12, 2012 in Uncategorized
Tags:

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.

Comments
  1. Hi, Sorry to being naive, after reading this article I got the good idea of 3 legged scenario but still confused about 2 legged, can you please add an example for 2 legged and explain this scenario in the light of that example. As you have mentioned(or I understood wrong) the user is not involved then whose resource client want to access from server.

    Thanks in advance.

  2. Click here says:

    In processing these dynamics, the growing company was able
    to identify a problem that resulted from the expansion of the organization. Last but not the least
    healthier business is directly proportional to engaged employees.
    Wirsz believes that even though we all have challenges to overcome,
    we must put ourselves up to the task.

  3. shortner says:

    When someone writes an piece of writing he/she maintains the image of a user in his/her mind
    that how a user can be aware of it. So that’s why this article is
    perfect. Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s