[13] 通常の OAuth の処理 (3-Legged OAuth) に対して、 (サーバーとクライアントだけ関与して資源所有者がいないなどの理由で) 一部の処理を省いたものを、 0-Legged OAuth, 1-Legged OAuth, 2-Legged OAuth などと呼ぶようです。

[14] 明確な共通仕様は存在せず、色々なサーバーがそれぞれの形態で実装しています。 概ね似たようなものですが、細部には違いがあるようです。

[15] いずれも OAuth 1.0 の認証された要求を用いるものです。

[1] OAuth 1.0 for Web Applications - Google Accounts Authentication and Authorization — Google Developers ( 版) https://developers.google.com/accounts/docs/OAuth#GoogleAppsOAuth

[2] OAuth on Bitbucket - Bitbucket - Atlassian Documentation ( 版) https://confluence.atlassian.com/display/BITBUCKET/OAuth+on+Bitbucket

We support both 3-Legged and 2-Legged OAuth.

[3] camme/passport-http-2legged-oauth ( 版) https://github.com/camme/passport-http-2legged-oauth

[4] 2-legged OAuthによるAPIアクセス << mixi Developer Center (ミクシィ デベロッパーセンター) ( 版) http://developer.mixi.co.jp/appli/spec/mob/2-legged-oauth/

xoauth_requestor_id (モバイル版アプリ)リクエストパラメータとして送られてくるopensocial_owner_idを設定

(PC版アプリ)ViewerのIDを設定

[5] 2-legged OAuthによるAPIアクセス << mixi Developer Center (ミクシィ デベロッパーセンター) ( 版) http://developer.mixi.co.jp/appli/spec/touch/using_restful_api/2-legged-oauth-api-access/

mixiアプリにて利用可能なRESTful APIへアクセスするには、2-legged OAuthによる適切な署名が必要です。

[6] OAuth認証方法について - GREE Developer Center ( 版) https://docs.developer.gree.net/ja/globaltechnicalspecs/oauth

xoauth_requestor_id アプリを実行しているGREEユーザーID ユーザーからデベロッパー様サーバーへのリクエストに含まれる、クエリパラメータのopensocial_viewer_idの値(初回アクセス時のみ付与されます)

[7] OAuth認証方法について(GREE Platform for Feature Phone) - GREE Developer Center ( 版) https://docs.developer.gree.net/ja/technicalspecs/featurephone/oauth

xoauth_requestor_id アプリを実行しているGREEユーザーID ガジェットサーバーからデベロッパー様サーバーへのリクエストに含まれる、クエリパラメータopensocial_viewer_idの値

[8] リクエストの署名 - Smartphone App - Mobage Developers Documentation Center ( 版) https://docs.mobage.com/display/JPSA/REST_API_Signing_Request_JP

2-legged 方式と 3-legged 方式は基本的には同じ処理を行いますが、3-legged 方式では Access Token を OAuth パラメータのリストに加え、ハッシュ時のキーは Consumer Secret と Access Token Secret の両方を利用します。

[9] Spring Security Tutorial: 0-Legged OAuth 1.0 ( 版) http://codehustler.org/blog/spring-security-tutorial-0-legged-oauth-1-0/

The first question is what is 0-Legged OAuth? People usually confuse 2-Legged or 1-Legged OAuth for what is effectively 0-Legged OAuth.

What we’re going to be doing is by-passing all of the steps above (i.e. 0-Legs) and making use of the OAuth Signature for authentiation.

[10] Spring Security Tutorial: 2-Legged OAuth 1.0 ( 版) http://codehustler.org/blog/spring-security-tutorial-2-legged-oauth-1-0/

Although the Spring documentation has a page regarding 2-Legged OAuth 1.0, this is in fact not a 2-Legged implementation. If you look at our post on 0-Legged OAuth 1.0 you will notice that this is what is actually implemented by the Spring OAuth library.

Personally I would recommend using 0-Legged OAuth rather than using the 2-Legged version which simply introduces extra trips back and forth between the consumer and the provider.

[11] Technical details of UserVoice API - UserVoice Developer (UserVoice 著, 版) https://developer.uservoice.com/docs/api/technical-details/

2-legged OAuth requests- Requests made on behalf of the client not on behalf of any specific user (see any API endpoints marked as requiring a Trusted Client) ex: Retrieving all users for a site, Getting a list of ideas for a private forum.

[12] Authentication — Marketplace API 2.0 documentation ( 版) http://firefox-marketplace-api.readthedocs.org/en/latest/topics/authentication.html

Marketplace provides OAuth 1.0a, allowing third-party apps to interact with its API. It provides it in two flavours: 2-legged OAuth, designed for command line tools and 3-legged OAuth designed for web sites.