2-leggedと3-leggedの勉強

OAuth

2-legged OAuth for the OpenSocial REST API - Google's Internet Identity Research
この記事の部分をとりあえず訳す

2-legged or 3-legged
The OAuth term is most frequently used when referring to 3-legged OAuth. This was a standardized version of a protocol that many vendors like Yahoo, Google, AOL, etc. had deployed which involved an end-user going through a "dance" where they start on the OAuth consumer site, and are redirected to the OAuth provider site where they are asked to approve access by the consumer site to their data. If their approval is given, they are then bounced back to the OAuth consumer site. While this "dance" has enabled a whole net set of applications and data-interoperability, the user experience can be confusing for an end-user (sort of like ballroom dancing with two partners at the same time).

2-legged OAuth is a term that is used to refer to another variant of OAuth which does not require this dance. This variant is also called Signed Fetch or Phone Home, especially in the OpenSocial community. In fact, the vast majority of actual REST API calls made on the Internet using OAuth are made using 2-legged OAuth, not 3-legged OAuth. The reason for that is that this is the feature that allows a gadget to make a connection back to the home server's of the developers who created the gadget. The following blog post contains an early description of this gadget feature:
http://opensocialapis.blogspot.com/2007/11/improved-content-fetching-for.html
This Signed Fetch feature of OpenSocial allows a gadget to "phone home" to its home servers. The reason the OAuth dance is avoided is because those home servers do not have any pre-existing information about the end-user, so there is no need for the end-user to give approval to access that non-existing data.

2-legged と 3-legged

OAuth という語は 3-legged OAuth を指すときに非常に頻繁に使われます。これは、 YahooやGoogle、AOLなどの多くのベンダーが展開している標準的な protocol のバージョンで、これは、 OAuth のコンシューマサイト上で始まり、 OAuth プロバイダサイトへリダイレクトされ、そこでコンシューマサイトに対してエンドユーザはデータへのアクセスを許可することを訪ねられる「ダンス」を通した処理に関わっています。
もし、許可が得られれば、エンドユーザは OAuth コンシューマサイトへと戻されます。
このダンスによって、アプリケーションとデータの相互運用を可能にしている一方で、ユーザ経験は、エンドユーザに対して混乱を生じさせます（同時に2つのパートナーとで社交ダンスを踊るようなものです）。

2-legged OAuth はこのダンスを必要としない改良型の1つをサス言葉として用いられます。
この改良型は、特に OpenSocial コミュニティでは、「Signed Fetch」や「Phone Home」としても呼ばれます。実際に、OAuth を利用したインターネット上の存在している REST API の呼び出しの大半が 2-legged OAuth でできており、3-legged OAuth ではありません。この理由は、ガジェット開発者のホームサーバへと戻るコネクションを作ることをガジェットに許可する特徴のためです。次のブログポストでは、この気ジェットの特徴の初期の説明があります。
http://opensocialapis.blogspot.com/2007/11/improved-content-fetching-for.html
OpenSocialの Signed Fetch の特徴によって、ガジェットはホームサーバへと「電話をかける」ことが可能になります。 OAuthダンスが避けられるのは、ホームサーバがエンドユーザについての事前情報を持っておらず、それゆえ、エンドユーザに対して、存在しないデータへのアクセスを許諾する必要が無いからです。

訳したけどいまいちピンとこない…

「pythonで署名付きリクエストを送る(2-legged OAuth) « taichino.com」の記事では、2-leggedはコンシューマとプロバイダの間の共通鍵認証で、通信間で授受されるデータが改竄されていないかの確認として用いられる。


OAuthと周辺技術の勉強会
—
ありえるえりあ
にある典型的シナリオを読んで、少しわかったような気がする。
以下も読んでおくこと

ソースコード読んでおくこと

こちらを激しく参考にさせていただきました。
500 Internal Server Error