2-leggedがうまく機能するのに3-legged OAuth2があるのはなぜですか？
2-legged OAuth2はブラウザーベースのアプリで使用され、クライアントの資格情報をパブリックに非表示にすることはできません。 3-legged OAuth2は、サーバー間で3番目の呼び出しが行われる「Webサーバーアプリ」で使用されます。 ここですべて説明 。
質問：2本足で問題ないように見えるのに、なぜ3本足で悩むのですか？
プロバイダーとクライアントの両方にとってより多くの作業です。ビッグプレーヤーの1人が移動せず、3脚を削除しなかったのはなぜですか？
三脚は、「ブラウザベース」のような特定のタイプのアプリを意味しません。 3レッグとは、アプリケーションがユーザーの直接の代理として機能することを意味します。 3つの脚のあるシナリオには
- アプリケーション（消費者）、
- ユーザー（リソース所有者）および
- aPI（サービスプロバイダー）。
2つの脚のあるシナリオでは、ユーザーの概念はありません。通常、これはアプリケーション間のソリューションに関係しています。そこでは、アプリケーション（消費者）が自分自身のために動作します。つまり、2つのレッグOAuthには次のようなものがあります。
- アプリケーション（消費者）、
- aPI（サービスプロバイダー）
違いは単純に、2-leggedアプローチではユーザー認証ステップが必要ないことです。
2-leggedシナリオが存在します。たとえば、 Google Appsドメイン全体の権限の委任 に関するドキュメントを確認してください。もちろん、それらは信頼できる環境でのみアカウントのスーパーオーナーが使用できます-上記の例では、Google Appsドメイン管理者は、管理しているドメインのすべてのユーザーアカウントのスーパーオーナーです。
3 LeggedはもちろんオープンWeb環境で使用する必要があります。サードパーティアプリケーションにデータへのアクセスを許可するには、リソース所有者の承認が必要です。