Backup of xtra/OAuth1.0 (No. 5)
OAuth Core 1.0 仕様 日本語訳概要OAuth プロトコルを使うと、ウェブサイトやアプリケーション（コンシューマ）が、 API経由でウェブサービス（サービスプロバイダ）にある保護されたりソース（情報）にアクセスできるようになります。 またこの際に、ユーザがサービスプロバイダに提出している認証情報（credential）をコンシューマに明かすことなく、 アクセスできるようにします。 平たく言うと、OAuthはAPI認証におけるフリーで汎用的な手法を提供します。 例を挙げるとすると、photos.example.net におけるユーザの認証情報（Credential）を明かすことなく、 印刷サービスサイト printer.example.com （コンシューマ）が photos.example.net（サービスプロバイダ）に保存されている写真にアクセスできるようにする、 といった場面が想定されます。 OAuth では、特別なユーザインターフェースや手順は必要ありませんし、 サービスプロバイダがユーザをどう認証するかも指定しません。 ですので OpenID のように、コンシューマ側がユーザの認証情報を取得しないようなケースに理想的に使えるプロトコルになっています。 認証委譲を行う Web サービスにおける利用感覚や実装を、ひとつのコミュニティ駆動なプロトコルのもとに集約することが OAuth の狙いです。 さまざまなウェブサイトで個別に実装されている既存のプロトコルやベストプラクティスの上に、OAuth は構築されています。 オープンな標準で、大小さまざまなプロバイダがサポートする標準であれば、 アプリケーション開発者とアプリケーションユーザの双方にとって、 一貫性があって信頼性のある利用感覚のあるものになっていくでしょう。 ライセンスこの仕様は OAuth Non-Assertion Convenant and Author's Contribution License For OAuth Specification 1.0
( http://oauth.net/license/core/1.0 この翻訳も同様に Create Commons BY-SA 3.0 の下にライセンスされます。 目次1 著者
翻訳
2 表記と用法このドキュメント中で使われる用語 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、RFC2119 で記載されている用法です。 例に使うドメイン名は RFC2606 のものを使っています。 3 用語
4 サービスプロバイダ文書と登録作業OAuth では、（ユーザと異なり）コンシューマキーと対応するコンシューマシークレットを使って、 サービスプロバイダに対してコンシューマを認証します。 コンシューマ個別にIDが与えられることで、サービスプロバイダはコンシューマに対して、 さまざまなアクセスレベルを提供することができるようになります （たとえばリソースに対するスロットリングなしのアクセスなど）。 コンシューマシークレットがコンシューマやサービスプロバイダ以外の誰からもアクセスできないことが確証できない限り、 サービスプロバイダはコンシューマのIDを確認する方法としてコンシューマシークレットに頼るべきではありません(SHOULD NOT)。 コンシューマシークレットは空文字でも構いません(MAY) （たとえばコンシューマの確認が必要なくて、RSA など他の方法で確認ができる場合など）。 4.1 Request URLOAuth では 3 つの URL を定義しています。（訳注：サービスプロバイダ文書に記載されます。）
この 3 つの URL は scheme, authority, path を含んだ形で記載されていなければならず(MUST)、 RFC3986 Section 3 に記載されているクエリーストリングやフラグメントを持っていても構いません(MAY)。 これらの Request URL では OAuth プロトコルパラメータをクエリー部に持っていてはいけません(MUST NOT)。 たとえば： http://sp.example.com/authorize 4.2 サービスプロバイダサービスプロバイダは責任をもって、コンシューマデベロッパがコンシューマキーとコンシューマシークレットを 発行できるようにしなければなりません。 これらを提供する際の手順や要求項目は、サービスプロバイダが自由に決めることができます。 サービスプロバイダ文書には次のものが記載されます。
4.3 コンシューマコンシューマ開発者はコンシューマキーとコンシューマシークレットをサービスプロバイダとの間に確立しなければなりません(MUST)。 コンシューマ開発者はサービスプロバイダへの登録の際に追加の情報を要求されることがあるかもしれません(MAY)。 5 パラメータOAuth プロトコルパラメータ名や値は大文字小文字を区別します。OAuthプロトコルパラメータは ひとつのリクエストにつき一回ずつしか現れてはいけません(MUST NOT)し、特に断りのない限り必要です(REQUIRED)。 5.1 パラメータエンコーディング全てのパラメータ名と値は RFC3986 のパーセントエンコーディング(%xx)メカニズムでエスケープされます。 非制限文字一覧 (RFC3986 section 2.3) にないものは、必ずエンコードしなければなりません(MUST)。 非制限文字一覧にある文字はエンコードしてはいけません(MUST NOT)。 エンコードした Hex 文字列は全て大文字にしなければなりません(MUST)。 テキストの名前や値は UTF-8 オクテットとしてエンコードしてからパーセントエンコードしなければなりません(RFC3629)。 （非制限文字は次の通り。） unreserved = ALPHA, DIGIT, '-', '.', '_', '~' 5.2 コンシューマリクエストパラメータOAuth プロトコルパラメータはコンシューマからサービスプロバイダに向かって、次の 3 種類のいずれかの方法を使って送信されます。 好ましい順に：
これらの 3 つの定義された方法に加えて、OAuth プロトコルパラメータを送る代替手段が将来追加されるかもしれません。 他のリクエストパラメータをどう送るかについては未定義ですが、OAuth HTTP Authorization Scheme ヘッダを使ってはいけません(SHOULD NOT)。 5.3 サービスプロバイダレスポンスパラメータサービスプロバイダからコンシューマに送信される際、トークンやその他情報のレスポンスパラメータは HTTP レスポンスボディを使って送られます。 RFC3986 Section 2.1 に記載されている通りに、パラメータ名や値は パラメータエンコーディングの方法でまずエンコードされ、 （訳注：パラメータ名と値は '=' で連結したのち、パラメータ名と値のセット同士を） '&' 文字（ASCII コードで 38）で連結されます。 oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b 5.4 OAuth HTTP 承認スキームOAuth では RFC2617 の拡張仕様を定義しています。OAuth では、HTTP標準の Authorization ヘッダと WWW-Authenticate ヘッダが使われます。 サービスプロバイダは HTTP Authorization ヘッダを解釈するのが望ましいです(RECOMMENDED)。 コンシューマは OAuth Authorization ヘッダにOAuth プロトコルパラメータを格納して送るべきです(SHOULD)。 認証スキーム（RFC2617で定義されている）は、「OAuth」でこれは大文字小文字を区別します。 5.4.1 Authorization ヘッダOAuth プロトコルパラメータは次の手順で Authorization ヘッダに格納されて送信されます。
例えば（訳注：長いので folding で複数行に分かれるようにしています。 folding する際は先頭に空白を入れることに注意してください。 folding しない場合は改行せずに一行に収めなければなりません。）： 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" 5.4.2 WWW-Authenticate ヘッダ保護されたリソースにサービスプロバイダがリクエストした際の応答に OAuth HTTP WWW-Authenticate ヘッダをつけることで、 サービスプロバイダがOAuth 拡張をサポートしていることを表現しても構いません。 RFC2617 には、そのようなレスポンスで HTTP-Authenticate ヘッダを付けてもよいとされています("MAY")。 例えば： WWW-Authenticate: OAuth realm="http://sp.example.com/" RFC2617 section 1.2 に記載されているように、realm パラメータが保護 realm を示しています。 6 OAuth 認証OAuth 認証のプロセスは、認証情報を共有することなく、ユーザの保護されたリソースに対してコンシューマがアクセスすることを許可するプロセスです。 OAuth ではユーザの認証情報の代わりに、サービスプロバイダ側で生成したトークンを使って保護されたりソースにリクエストをします。 手続きの中で二つのタイプのトークンを使います：
OAuth 認証は次の 3 つの段階で行われます。
 6.1 未認証のリクエストトークンを取得するコンシューマはサービスプロバイダにトークンの発行を依頼して、未承認のリクエストトークンを取得します。 リクエストトークンの唯一の目的は、ユーザの認定を受けてアクセストークンを取得することだけです。 リクエストトークンに関する処理は次のように進みます： 6.1.1 コンシューマがリクエストトークンを取得するリクエストトークンを取得するに、コンシューマはサービスプロバイダのリクエストトークン URL に HTTP リクエストを送信します。サービスプロバイダのドキュメントでは、このリクエストで使われる HTTP method が指定されているでしょうし、HTTP POST が推奨(RECOMMENDED)です。 リクエストは必ずサインされていて、かつ、次のパラメータを持っていなければなりません(MUST)。
6.1.2 サービスプロバイダが未承認リクエストトークンを発行するサービスプロバイダは署名とコンシューマキーを確認します。 成功すれば、リクエストトークンとトークンシークレットを生成して、 それを「サービスプロバイダの応答パラメータ」の形式に従って HTTP レスポンスボディに格納して コンシューマに送り返します。 ユーザが「ユーザの承認を得る」手順でアクセスを許可するまで、リクエストトークンが アクセストークンに変換できないようにしなければなりません(MUST)。 レスポンスには次のパラメータがあります:
リクエストの確認が失敗したり、その他の理由で拒否されてしまった場合、 サービスプロバイダは「HTTP レスポンスコード」で定義されている 適切な HTTP レスポンスコードを返すべきです(SHOULD)。 6.2 ユーザの承認を得るユーザが承認するまで、コンシューマはリクエストトークを使うことができません。 ユーザの承認を得る手順は次のようなものです: 6.2.1 コンシューマがユーザをサービスプロバイダに案内するリクエストトークンをアクセストークンに変換できるようにするために、 コンシューマは、ユーザをサービスプロバイダに送って同意を得るようにしなければなりません(MUST)。 サービスプロバイダの認証 URL に次のパラメータを付けた形で HTTP GET リクエストが 起こるように、コンシューマは URL を組み立てます。
リクエスト URL が構築されると、コンシューマはユーザのブラウザを使ってユーザをその URL に リダイレクトします。 コンシューマが HTTP リダイレクションができない場合は、コンシューマは構築した URL に 行くようにユーザに指示しても構いません(SHALL)。 注: コンシューマが携帯デバイスやセットトップボックスで動作していることを、 サービスプロバイダが知っている場合は、サービスプロバイダはユーザ承認 URL や リクエストトークンが手動入力するのに適しているものであるようにすべきです(SHOULD)。 6.2.2 サービスプロバイダはユーザを認証して、同意を取るサービスプロバイダはユーザの ID を確認して、詳細についての利用同意を確認します。 OAuth仕様では、サービスプロバイダがユーザをどう認証するかは定義していません。 しかし、必須の (REQUIRED) 手順は定義しています。
ユーザに、コンシューマキーに基づいて得られたコンシューマの識別情報を提示する場合、 サービスプロバイダはコンシューマの本当の識別情報を取得することができないかどうかをユーザに 知らせなければなりません(MUST)。 サービスプロバイダがこの識別情報がどの程度確かなものかを保障するかは、この仕様の範囲外です。 6.2.3 サービスプロバイダがユーザをコンシューマに案内するユーザの認証をしてコンシューマアクセスがサービスプロバイダに認められた後、 リクエストトークンが承認されてアクセストークンに変換できる状態になったことを コンシューマは知らせられなければなりません(MUST)。 ユーザが拒否した場合、コンシューマはリクエストトークンが破棄されたことを通知されてもかまいません(MAY)。 コンシューマが oauth_callback (「コンシューマがユーザをサービスプロバイダに案内する」で記載) を使って callback URL を指定してきた場合、サービスプロバイダは HTTP GET リクエストの URL を構成し、 次のパラメータをつけてユーザのウェブブラウザをリダイレクトします。
callback URL はコンシューマがつけたクエリーパラメータを含めてもかまいません(MAY)。 サービスプロバイダはこれらを変更することなく、既存のパラメータにそのまま oauth_token パラメータを 連結しなければなりません(MUST)。 callback URL がない場合は、ユーザがコンシューマに認証が完了したことを手動で伝えなければならないことを、 サービスプロバイダはユーザに提示しなければなりません。 6.3 アクセストークンの取得コンシューマは、リクエストトークンを保護リソースにアクセスすることのできるアクセストークンに変換します。 アクセストークンの取得はつぎのステップを踏みます。 6.3.1 コンシューマがアクセストークンを要求するリクエストトークンとトークンシークレットは、アクセストークンとトークンシークレットと 交換されなければなりません(MUST)。 アクセストークンを要求するには、コンシューマはアクセストークン URL に HTTP リクエストを発行します。 サービスプロバイダのドキュメントでは、このときのリクエストで使われる HTTP メソッドを指定しなければなりませんが、 HTTP POST が推奨されています(RECOMMEND)。 リクエストは「リクエストの署名」の方法に従って署名されていなければならず(MUST)、 次のパラメータを含んでいます。
アクセストークンをリクエストする際には、サービスプロバイダ特有の追加パラメータをつけてはいけません。 これはトークンに紐付くすべての情報が、ユーザの同意を取る前に提示されているようにするためです。 6.3.2 サービスプロバイダがアクセストークンを承認するサービスプロバイダは次のことを確認しなければなりません(MUST)。
もし確認が取れれば、サービスプロバイダはアクセストークンとトークンシークレットを生成して、 「サービスプロバイダ応答パラメータ」で記載されているように、HTTP レスポンスボディに格納して送り返します。 アクセストークンとトークンシークレットはコンシューマに保存され、保護りソースに署名する際に使われます。 応答には次のパラメータが含まれます。
確認が取れていなかったり、それ以外の理由により拒否された場合は、サービスプロバイダは 「HTTP レスポンスコード」で定義されている適切な応答コードを返すべきです(SHOULD)。 「サービスプロバイダ応答パラメータ」で定義されているように、リクエストが失敗した理由についての より詳細な情報を HTTP レスポンスボディ中に含めてもかまいません(MAY)。 7 コンシューマが保護リソースにアクセスするアクセストークンとトークンシークレットを無事受け取った後、コンシューマはユーザに成り代わって 保護リソースにアクセスできるようになります。 リクエストは「署名リクエスト」ごとに署名しなければならず(MUST)、次のパラメータを含んでいなければなりません。
8 Nonce とタイムスタンプサービスプロバイダから特に指定がない限り、タイムスタンプは 1970年1月1日の0時0分0秒(GMT)からの秒数で表現されます。 タイムスタンプの値は正の整数でなければならず(MUST)、以前のリクエストと同じか大きくなければなりません(MUST)。 そのタイムスタンプを持つすべてのリクエストについて、コンシューマは Nonce 値生成するでしょう(SHALL)。 nonce はランダム文字列で、各リクエストごとにユニークになるように生成されます。 Nonce を使うことで、サービスプロバイダはそのリクエストが以前発行されたものではないことを確認し、 セキュアでない通信路(HTTPなど)上でのリプレイアタックを防ぎます。 9 リクエストの署名すべてのトークンつきリクエストや保護リソースへのリクエストは、コンシューマ側で署名し、 サービスプロバイダ側でその署名を検証しなければなりません。 トークンリクエストや保護されたりソースに対するリクエストを行う際に、承認されていないパーティが コンシューマキーやトークンを使うことを防止するために、リクエストに署名をします。 署名のプロセスの中で、コンシューマシークレットとトークンシークレットは検証できる値にエンコードされて リクエストの中に格納されます。 個々の実装ではそれぞれに固有の事情があるでしょうから、OAuth 仕様では特定の署名方法を指定することはしません。 プロトコルでは 3 種類の署名方法 HMAC-SHA1, RSA-SHA1, PLAINTEXT を定義していますが、 サービスプロバイダは自身で定義する方法で実装することができます。 これ以外の特定の署名方法を推奨することは、この仕様の範囲外とします。 コンシューマは oauth_signature_method パラメータで使用する署名方法を宣言し、署名を生成し、 署名の値を oauth_signature パラメータに保存します。 サービスプロバイダは署名方法に指定されている従って署名の値を検証します。また、 コンシューマの署名を検証する際には、サービスプロバイダはリクエストについている Nonce の値を チェックして以前同じコンシューマリクエストが使われていないか確認するべきです(SHOULD)。 署名プロセスでは、oauth_signature パラメータを除き、リクエストパラメータ名や値を変更してはいけません(MUST NOT)。 9.1 署名ベース文字列署名ベース文字列は、リクエストの要素を復元できる形でひとつの文字列に連結したものです。 この文字列は hashing や署名アルゴリズムの入力値として使われます。 HMAC-SHA1 署名方法を標準的な方法として、署名を生成する際に署名ベース文字列を使う例を示します。 署名ベース文字列を構築する前に、全てのリクエストパラメータは「パラメータのエンコード方法」に 記載されている方法で、エンコードされていなければなりません。 9.1.1 リクエストパラメータの正規化リクエストパラメータは収集、ソート、正規化されてから、文字列に連結されます:
oauth_signature パラメータは除外されていなければなりません。 パラメータは次の手順でひとつの文字列に正規化されます。
9.1.2 リクエスト URL を構成する署名ベース文字列はリクエストの絶対 URL を含み、署名が特定のエンドポイントにのみ有効であるようにします。 署名ベース文字列で使われる URL は scheme, authority, path を含まなければならず(MUST)、 RFC3986 section 3 に従って、クエリーストリングやフラグメントは除外しなければなりません(MUST)。 もしリクエストの絶対 URL がサービスプロバイダで取得できない場合（コンシューマでは常に取得できますけれども）、 使われている scheme と HTTP Host ヘッダと HTTP リクエストに現れる相対 URL から構築することもできます。 もし Host ヘッダがない場合、サービスプロバイダはドキュメントやその他の方法で指定した コンシューマと通信に使うであろうホスト名を使うべきです(SHOULD)。 URL 正規化の際にあいまいさがでないように、 サービスプロバイダは署名ベース文字列に使われる URL の形式をドキュメントに記載すべきです(SHOULD)。 指定がない場合、URL スキームや authority は小文字でなければならず (MUST)、ポート番号を含めなければなりません(MUST)。 ただし http のデフォルト 80 番と https のデフォルトの 443 番は含めてはいけません(MUST)。 たとえば HTTP://Example.com:80/resource?id=123 は、署名ベース文字列では次のような形で含まれます。 http://example.com/resource 9.1.3 リクエストの要素を連結する次の要素をひとつの文字列に連結しなければなりません(MUST)。各アイテムはエンコードされて、 要素が空でも '&' 文字（ASCII code 38）で区切られていなければなりません。
署名ベース文字列の例については Appendix A.5.1 を参照してください。 9.2 HMAC-SHA1HMAC-SHA1 署名方法では、RFC2104 で定義されている HMAC-SHA1 署名アルゴリズムを使い、 RFC2104 での text は署名ベース文字列で、key はコンシューマシークレットとトークンシークレットを （まずパラメータエンコーディングしてから）'&' 文字 (ASCII code 38) で連結した値です。 空でも連結します。 9.2.1 署名の生成oauth_signature は計算して導出した digest のオクテット文字列を base64 エンコーディング（RFC2045 section 6.8に従う）し、 その後「パラメータエンコーディング」に従って URL エンコードされる。 9.2.2 署名の検証サービスプロバイダは新しいリクエストオクテット文字列を生成して、コンシューマが送ってきた署名をまず URL デコードしさらに base64 デコード（RFC2045 section 6.8 に従う）し、両者が一致するかをもって検証を行います。 コンシューマから与えられるリクエストパラメータ、サービスプロバイダに保存されているコンシューマシークレットと トークンシークレットを使って署名は生成されます。 9.3 RSA-SHA1RSA-SHA1 署名方法は、RFC2447 section 8.2 で定義されている RSASSA-PKCS1-v1_5 署名アルゴリズム （PKCS#1としてよく知られています）を使い、EMSA-PKCS1-v1_5 のハッシュ関数として SHA-1 を使います。 コンシューマの RSA 公開鍵が確かな手段でコンシューマからプロバイダに提供されているとします。 この手段については、本仕様の範囲外とします。 9.3.1 署名の生成RFC3447 section 8.2.1 に従って、署名ベース文字列はコンシューマの RSA 秘密鍵で署名されます。 K をコンシューマの RSA プライベート鍵、M を署名ベース文字列として、S が署名のオクテット文字列です。 S = RSSA-PKCS1-V1_5-SIGN (K, M) rfc2045 SECTION 6.8 に従って S を base64 エンコードし、さらに「パラメータエンコーディング」に従って URL エンコードしたものが oauth_signature になります。 9.3.2 署名の検証RFC3447 section 8.2.2 に従って、サービスプロバイダは署名を検証します。 (n, e) をコンシューマの RSA 公開鍵、M を署名ベース文字列として、 S が oauth_signature 値のオクテット文字列表現となります。 RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S) 9.4 PLAINTEXTPLAINTEXT 方法では、セキュリティ的な保護はされませんので、HTTPS といったセキュアな 通信路上で使用すべきです(SHOULD)。署名ベース文字列は使いません。 9.4.1 署名の生成oauth_signature はコンシューマシークレットとトークンシークレットを「パラメータエンコード」して '&' 文字（ASCII code 38） 区切りで連結したものです。空でも連結します。得られた結果は再度エンコードしなければなりません。 次の例では 3 つの異なるトークンシークレットについて oauth_signature の値がどのようになるかを示しています。
9.4.2 署名の検証サービスプロバイダは署名の値をコンシューマシークレットとトークンシークレットに分解して、 手元に保存されているシークレットと一致するかを検証します。 10 HTTP レスポンスコードこの章の内容はリクエストトークンとアクセストークンリクエストにのみ適用されます。 一般的には、サービスプロバイダは RFC2616 Section 10 で定義されているレスポンスコードを使うべきです(SHOULD)。 サービスプロバイダがコンシューマのリクエストを拒否する際には、HTTP 400 Bad Request あるいは HTTP 401 Unauthorized のレスポンスを返すべきです(SHOULD)。
Appendix略。 11 参考文献
著者のアドレスOAuth Core Workgroup Email: spec@oauth.net 訳に関する問い合わせは kwi@i-revo.co.jp にお願いします。 |
|
Modified by i-revo labs.
Powered by PukiWiki Plus! 1.4.7plus-u2-i18n/PHP 5.2.17. HTML convert time to 0.228 sec. |
|
© 2006-2008 Internet Revolution