2 legged OAuth & 3 legged OAuth

English

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

Chinese

3-legged oauth

resource owner, client, server.

resource owner 给client访问权限去访问resource owner在server上的resource，但是resource owner和client不共享credentials（用户名和密码）。

1. client在server上注册，获得client credentials（包括consumer key和consumer secret）

2. client从server获得temporay credentials（即request token）

3. client将user-agent定向到server

4. user授权client访问server上的resource

5. server将user-agent定向到client

6. client用temporary credentials(request token)从server换取token credentials（即 access token）

7. client使用access token访问server上的protected resource

2-legged oauth

没有user参与的 server/client形式

1. client在server上注册，获得client credentials（包括consumer key和consumer secret）

2. client使用client credential（和空的token credential）访问server上的protected resource

三条腿的OAuth（3-Legged OAuth），这也是OAuth的标准版本。这里所谓的“三条腿”，指的是授权过程中涉及前面提到的三种角色，也就是：客户端，服务提供方，用户。不过有 些情况下，不需要用户的参与，此时就产生了一个变体，被称作两条腿的OAuth（2-Legged OAuth），一般来说，访问私有数据的应用需要三条腿的OAuth，访问公共数据的应用需要两条腿的OAuth。
两条腿的OAuth和三条腿的OAuth相比，因为没有用户的参与，所以在流程中就不会涉及用户授权的环节，也就不需要使用Token，而主要是通 过Consumer Key和Consumer Secret来完成签名的，此时的Consumer Key和Consumer Secret基本等价于账号和密码的作用。

Japanese

Auth Coreはフロー上の登場人物がConsumerとSPとEnd Userの三者であることから3-legged OAuthと呼ばれているのに対し、ConsumerがEnd Userとは紐づかないSPのリソースにアクセスする２者間通信の仕組みを通称2-legged OAuthと呼んでいます。

Refrence:
http://maeshima.hateblo.jp/category/oauth
http://www.tuicool.com/articles/6JnmMn
http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
https://drupal.org/node/1839550
http://www.kaiyuanba.cn/html/1/131/227/7672.htm
http://baike.baidu.com/view/6619164.htm
http://techblog.yahoo.co.jp/web/auth/oauth_1/