V1.0 http://oauth.net/core/1.0/
OAuth includes a Consumer Key and matching Consumer Secret that together authenticate the Consumer (as opposed to the User) to the Service Provider. Consumer-specific identification allows the Service Provider to vary access levels to Consumers (such as un-throttled access to resources). OAuthは、サービス･プロバイダに対して、 Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA).
OAuthでは3つのリクエストURLを定義する。
これら3つのURLは、スキーム、オーソリティ、およびパスを<<含むことが必須であり>>、クエリおよびRFC3986の第3章で定義されるフラグメントを<<含んでもよい>>。リクエストURLのクエリは、いかなるOAuthプロトコル･パラメータを<<含んではならない>>。例えば、
http://sp.example.com/authorize
サービスプロバイダの責務は、コンシューマの開発者が、コンシューマ鍵とコンシューマ秘密情報を設置する(証明する？？)ことを可能にすることである。 これら鍵と秘密データの準備に関する処理と要求は、もっぱらサービスプロバイダの義務である。 プロバイダの文書は以下の項目を含む。
コンシューマ･デベロッパは、コンシューマ鍵とコンシューマ･シークレットをサービス･プロバイダとの間で<<確立しなければならない>>。 コンシューマ･デベロッパは、サービスプロバイダに対して付加情報を登録時に提供する必要がある場合がある。
OAuthプロトコル・パラメータの名前、値はそれぞれ大文字・小文字を区別する。 OAuthプロトコル・パラメータは、一つのリクエスト中に複数回表れてはいけない。また？？？ and are REQUIRED unless otherwise noted.
すべてのパラメータ名および値は、 [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .参照)の％エンコード機構を用いてエスケープされる。 予約 されていない文字セット([RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” . の２．３節参照)にない文字(群)は、エンコードしなければならない。 予約 されていない文字セットに含まれる文字(群)は、エンコードしてはならない。 16進文字はエンコード結果中で大文字でなければならない。 Text名と値は、％エンコードより前にUTF-8でエンコードしなければならない[RFC3629] (Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .参照)。
unreserved = ALPHA, DIGIT, '-', '.', '_', '~'
OAuthプロトコル・パラメータは、以下のいずれかの手法でコンシューマからサービス・プロバイダーに送られる。(1から3は望ましい順)
その他のパラメータを送る方法は未定義のままであるが、OAuth HTTP認可スキームでのヘッダを用いるべきではない。
レスポンス・パラメータはサービス・プロバイダによって送信され、トークンとその他の情報をコンシューマに、HTTPレスポンス・ボディ中に返す。 パラメータ名と値は、最初にパラメータ・円コーディングされ、「&」文字で結合される。(Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) Section 2.1参照) 例えば、
oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b
本節では、OAuthをサポートするための[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)に対する拡張を定義する。
この定義は、OAuthプロトコル・パラメータを引き渡すため、標準のHTTP AuthorizationおよびWWW-Authenticateヘッダを使用する。
サービス・プロバイダは、HTTP Authorizationヘッダを受け入れることが推奨される。コンシューマは、OAuthプロトコル・パラメータをOAuth Authorization ヘッダ中にいれて送るべきである。 auth-scheme拡張はOAuthであり、大文字小文字を判別する。
OAuthプロトコル・パラメータは、Authorizationヘッダ中で、以下のように送られる。
OPTIONAL linear whitespace per [RFC2617] (Franks, J., Hallam-Baker, P.,
Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP
Authentication: Basic and Digest Access Authentication,” .).
例えば、
Authorization: OAuth realm="http://sp.example.com/",
oauth_consumer_key="0685bd9184jfhq22",
oauth_token="ad180jjd733klru7",
oauth_signature_method="HMAC-SHA1",
oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
oauth_timestamp="137131200",
oauth_nonce="4572616e48616d6d65724c61686176",
oauth_version="1.0"
サービスプロバイダは、コンシューマの保護されたリソースへの要求において、OAuth HTTP WWW-Authenticateヘッダを返すことで拡張のサポートを示しても良い
[RFC2617]のように、このようなレスポンスは、追加のHTTP WWW-Authenticate ヘッダを含む可能性がある。
例えば、
WWW-Authenticate: OAuth realm="http://sp.example.com/"
realmパラメータは、RFC2617 1.2節のように、保護対象の領域を定義する。
OAuth認証は、ユーザが自分のCredentialsを コンシューマと共有すること無しに、保護されたリソースへのアクセスを許可するプロセスである。
OAuthは、サービス・プロバイダが生成したトークンを、ユーザのCredentialsの替わりに 保護されたリソースへのアクセスで用いる。
このプロセスは以下の2つの形式のトークンを用いる。
コンシューマは、サービス･プロバイダにトークン･発行を要求することで、未認証のトークンを得る。 リクエスト･トークンの唯一の目的は、ユーザの承認を受信することで、アクセス･トークンを得るためにのみ使用できる。 リクエスト･トークンのプロセスは以下のようになる。
リクエスト･トークンを得るため、コンシューマは、サービス･プロバイダのリクエスト･トークンURLにHTTPリクエストを送信する。 サービス･プロバイダの文書では、この要求のためのHTTPメソッドの仕様を定めており、HTTP POST が推奨される。 リクエストは、署名された上、以下のパラメータを含んでいなければならない。
サービス･プロバイダーは、署名とコンシューマ鍵を検証する。 検証が成功すれば、サービス･プロバイダはリクエスト･トークンと、トークン秘密データを生成して、 サービス･レスポンス･パラメータで定義されたように、HTTP レスポンスボディ中にいれて返す。 サービス･プロバイダは、 ユーザの許可を得る家庭で、ユーザが首尾よくアクセスを許可するまで、 リクエストトークンが、アクセス･トークンと交換されないことを保証しなければならない。
レスポンスは、以下のパラメータを含む。
oauth_token:
リクエスト･トークン.
oauth_token_secret:
トークン･秘密データ.
Additional parameters:
サービス･プロバイダが定義するなんらかの追加パラメータ.
リクエストが検証に失敗するか、なんらかの理由で拒絶された場合、 HTTPレスポンス･コードで定義された適当なコードを返すべきである。
サービス･プロバイダは、リクエストの拒絶理由を示す詳細情報を、 サービス・プロバイダ･レスポンス･パラメータで定義される、HTTP レスポンス･ボディ中に入れて返しても良い。
コンシューマは、ユーザの許諾が得られるまで、リクエストトークンを使うことはできない。 ユーザの許諾を得るには以下のステップが含まれる。
コンシューマが、リクエストトークンをアクセス･トークンと交換できるようにするためには、 コンシューマは、 ユーザをサービス･プロバイダに案内することで、ユーザからの承認を得なければならない。 コンシューマは、HTTP GETリクエストを、サービス･プロバイダのユーザ認可URLに以下のパラメータをつけて、 作成する。
Additional parameters:
Any additional parameters, as defined by the Service Provider.
oauth_token:
オプション。前のステップで取得されたリクエスト･トークン。サービスプロバイダは、要求に応じてこのパラメータを宣言するか、このパラメータなしにユーザ承認URLに対するリクエストを受け付ける。
oauth_callback:
オプション。ユーザ承認(ユーザ承認参照)が完了した時、ユーザをコンシューマにリダイレクトして戻すためにサービスプロバイダが用いる。
Additional parameters:
サービスプロバイダが定義するその他のパラメータ
Once the request URL has been constructed the Consumer redirects the User to the URL via the User’s web browser. If the Consumer is incapable of automatic HTTP redirection, the Consumer SHALL notify the User how to manually go to the constructed request URL.
Note: If a Service Provider knows a Consumer to be running on a mobile device or set-top box, the Service Provider SHOULD ensure that the User Authorization URL and Request Token are suitable for manual entry.
The Service Provider verifies the User’s identity and asks for consent as detailed. OAuth does not specify how the Service Provider authenticates the User. However, it does define a set of REQUIRED steps:
* The Service Provider MUST first verify the User’s identity before asking for consent. It MAY prompt the User to sign in if the User has not already done so. * The Service Provider presents to the User information about the Consumer requesting access (as registered by the Consumer Developer). The information includes the duration of the access and the Protected Resources provided. The information MAY include other details specific to the Service Provider. * The User MUST grant or deny permission for the Service Provider to give the Consumer access to the Protected Resources on behalf of the User. If the User denies the Consumer access, the Service Provider MUST NOT allow access to the Protected Resources.
When displaying any identifying information about the Consumer to the User based on the Consumer Key, the Service Provider MUST inform the User if it is unable to assure the Consumer’s true identity. The method in which the Service Provider informs the User and the quality of the identity assurance is beyond the scope of this specification.
6.2.3. Service Provider Directs the User Back to the Consumer
After the User authenticates with the Service Provider and grants permission for Consumer access, the Consumer MUST be notified that the Request Token has been authorized and ready to be exchanged for an Access Token. If the User denies access, the Consumer MAY be notified that the Request Token has been revoked.
If the Consumer provided a callback URL in oauth_callback (as described in Consumer Directs the User to the Service Provider (Consumer Directs the User to the Service Provider)), the Service Provider constructs an HTTP GET request URL, and redirects the User’s web browser to that URL with the following parameters:
oauth_token:
The Request Token the User authorized or denied.
The callback URL MAY include Consumer provided query parameters. The Service Provider MUST retain them unmodified and append the oauth_token parameter to the existing query.
If no callback URL was provided, the Service Provider instructs the User to manually inform the Consumer that authorization has completed.
