2-legged vs. 3-legged OAuth
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.