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