Top > xtra > OAuth1.0

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 ) で利用できます。 著作権は Creative Commons Attribution - ShareAlike 3.0 license ( http://creativecommons.org/licenses/by-sa/3.0 ) の下にライセンスされます。

この翻訳も同様に Create Commons BY-SA 3.0 の下にライセンスされます。

目次


1 著者

翻訳

  • 川井浩陽 Hiroaki Kawai

2 表記と用法

このドキュメント中で使われる用語 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、RFC2119 で記載されている用法です。 例に使うドメイン名は RFC2606 のものを使っています。

3 用語

サービスプロバイダ
OAuth を使ってアクセスを受け付けるウェブアプリケーション
ユーザ
サービスプロバイダにアカウントを持っている個人
コンシューマ
ユーザになりかわってサービスプロバイダに OAuth でアクセスするウェブサイトやアプリケーション
保護されたリソース
サービスプロバイダの配下にあるデータで、認証語にコンシューマがアクセスできるようになるデータ。
コンシューマ開発者
コンシューマを実装している個人や組織
コンシューマキー
コンシューマがサービスプロバイダに自分自身を認識してもらうために使う値
コンシューマシークレット
コンシューマキーの所有を確立するために使われるシークレット。(訳注:共有鍵(対象鍵)で HMAC-SHA1, PLAINTEXT の時に使われる。)
リクエストトークン
ユーザの承認を得るためにコンシューマが使う値で、アクセストークンに変換される
アクセストークン
コンシューマがユーザに成り代わって保護されたりソースにアクセスするために取得した値で、 ユーザがサービスプロバイダに対して使っている認証情報の代わりに使う値
トークンシークレット
トークンの所有を確立するために使われるコンシューマが使うシークレット(訳注:シークレットとはいうものの、通信路が平文であれば一度は生で見えます。)
OAuth プロトコルパラメータ
oauth_ で始まる名前のパラメータ

4 サービスプロバイダ文書と登録作業

OAuth では、(ユーザと異なり)コンシューマキーと対応するコンシューマシークレットを使って、 サービスプロバイダに対してコンシューマを認証します(訳注:HMAC-SHA1, PLAINTEXTの場合)。 コンシューマ個別にIDが与えられることで、サービスプロバイダはコンシューマに対して、 さまざまなアクセスレベルを提供することができるようになります (たとえばリソースに対するスロットリングなしのアクセスなど)。

コンシューマシークレットがコンシューマやサービスプロバイダ以外の誰からもアクセスできないことが確証できない限り、 サービスプロバイダはコンシューマのIDを確認する方法としてコンシューマシークレットに頼るべきではありません(SHOULD NOT)。 コンシューマシークレットは空文字でも構いません(MAY) (たとえばコンシューマの確認が必要なくて、RSA など他の方法で確認ができる場合など)。

4.1 Request URL

OAuth では 3 つの URL を定義しています。(訳注:サービスプロバイダ文書に記載されます。)

リクエストトークン URL
承認されていないリクエストトークンを取得するのに使われる URL。Section 6.1 参照。
ユーザ認証 URL
コンシューマがアクセスするためのユーザの承認を取得するのに使われる URL。Section 6.2 参照。
アクセストークン URL
ユーザが承認したリクエストトークンをアクセストークンに交換するための URL。Section 6.3 参照。

この 3 つの URL は scheme, authority, path を含んだ形で記載されていなければならず(MUST)、 RFC3986 Section 3 に記載されているクエリーストリングやフラグメントを持っていても構いません(MAY)。 これらの Request URL では OAuth プロトコルパラメータをクエリー部に持っていてはいけません(MUST NOT)。 たとえば:

http://sp.example.com/authorize

4.2 サービスプロバイダ

サービスプロバイダは責任をもって、コンシューマデベロッパがコンシューマキーとコンシューマシークレットを 発行できるようにしなければなりません。 これらを提供する際の手順や要求項目は、サービスプロバイダが自由に決めることができます。

サービスプロバイダ文書には次のものが記載されます。

  1. コンシューマが OAuth リクエストを送信するのに使う URL の場所と、 リクエストトークン URL とアクセストークン URL で使われる HTTP method (GET, POST など)
  2. サービスプロバイダで利用可能な署名方法
  3. トークンを取得する際に必要な追加のリクエストパラメータ。 サービスプロバイダ特有のパラメータは oauth_ で始まってはいけません(MUST NOT)。

4.3 コンシューマ

(訳注:HMAC-SHA1, PLAINTEXTを使う場合)コンシューマ開発者はコンシューマキーとコンシューマシークレットをサービスプロバイダとの間に確立しなければなりません(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 種類のいずれかの方法を使って送信されます。 好ましい順に:

  1. 「OAuth HTTP 承認スキーム」で定義されている HTTP Authorization ヘッダ中
  2. HTTP POST リクエストのボディ部に content-type: application/x-www-form-urlencoded として
  3. URL のクエリー部に付加する (RFC3986 section 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 ヘッダに格納されて送信されます。

  1. パラメータ名と値は「パラメータエンコーディング」されます。
  2. パラメータ名直後に '=' 文字(ASCII code 61)、" 文字(ASCII code 34)、値(空文字かもしれません(MAY))、" 文字(ASCII code 34)と続きます。
  3. パラメータ同士の区切りは、カンマ(ASCIIコード44)でRFC2617の通り空白文字があってもかまいません(OPTIONAL)。
  4. RFC2617, secion 1.2 の通り realm パラメータがあっても構いません(OPTIONAL)。

例は次のようになります。(訳注:長いので 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 ではユーザの認証情報の代わりに、サービスプロバイダ側で生成したトークンを使って保護されたりソースにリクエストをします。 手続きの中で二つのタイプのトークンを使います:

リクエストトークン
コンシューマが保護されたリソースにアクセスすることをユーザに認めてもらう際に使われます。 ユーザが承認したリクエストトークンは、アクセストークンに変換されます。 リクエストトークンはまた、一度だけ使うことができて("MUST")、かつ、他の異なる目的に対しては使うことはできません("MUST NOT")。 リクエストトークンには有効期限を設定するのがよいでしょう("RECOMMENDED")。
アクセストークン
ユーザに成り代わってコンシューマが保護されたリソースにアクセスするときに使われます。 アクセストークンを使って特定の保護されたリソースへのアクセスを制限しても構いません(MAY)し、 アクセストークンに有効期限が設けられていても構いません(MAY)。 ユーザがアクセストークンを無効にできるように、サービスプロバイダはするべきでしょう。 保護されたリソースにアクセスするのに使うものは、アクセストークンだけでいいでしょう(SHALL)。

OAuth 認証は次の 3 つの段階で行われます。

  1. コンシューマは未承認のリクエストトークンを取得します。
  2. ユーザはそのリクエストトークンを承認します。
  3. コンシューマはリクエストトークンをアクセストークンに交換します。
diagram.png

6.1 未認証のリクエストトークンを取得する

コンシューマはサービスプロバイダにトークンの発行を依頼して、未承認のリクエストトークンを取得します。 リクエストトークンの唯一の目的は、ユーザの認定を受けてアクセストークンを取得することだけです。 リクエストトークンに関する処理は次のように進みます:

6.1.1 コンシューマがリクエストトークンを取得する

リクエストトークンを取得するに、コンシューマはサービスプロバイダのリクエストトークン URL に HTTP リクエストを送信します。サービスプロバイダのドキュメントでは、このリクエストで使われる HTTP method が指定されているでしょうし、HTTP POST が推奨(RECOMMENDED)です。 リクエストは必ずサインされていて、かつ、次のパラメータを持っていなければなりません(MUST)。

oauth_consumer_key
コンシューマキー
oauth_signature_method
コンシューマがリクエストにサインするのに使う署名方法
oauth_signature
「リクエストへの署名」で定義されている署名
oauth_timestamp
「Nonce とタイムスタンプ」で定義されています
oauth_nonce
「Nonce とタイムスタンプ」で定義されています
oauth_version
OPTIONAL。もしあればこの値は 1.0 でなければなりません(MUST)。 この値がない場合は、サービスプロバイダ側は 1.0 であったと期待しなければなりません(MUST)。 サービスプロバイダ側の 非 1.0 な値は、まだ定義されていません。
追加パラメータ
サービスプロバイダで定義されている任意の追加パラメータ

6.1.2 サービスプロバイダが未承認リクエストトークンを発行する

サービスプロバイダは署名とコンシューマキーを確認します。 成功すれば、リクエストトークンとトークンシークレットを生成して、 それを「サービスプロバイダの応答パラメータ」の形式に従って HTTP レスポンスボディに格納して コンシューマに送り返します。 ユーザが「ユーザの承認を得る」手順でアクセスを許可するまで、リクエストトークンが アクセストークンに変換できないようにしなければなりません(MUST)。

レスポンスには次のパラメータがあります:

oauth_token
リクエストトークン
oauth_token_secret
トークンシークレット
追加パラメータ
サービスプロバイダで定義されている任意の追加パラメータ

リクエストの確認が失敗したり、その他の理由で拒否されてしまった場合、 サービスプロバイダは「HTTP レスポンスコード」で定義されている 適切な HTTP レスポンスコードを返すべきです(SHOULD)。

6.2 ユーザの承認を得る

ユーザが承認するまで、コンシューマはリクエストトークを使うことができません。 ユーザの承認を得る手順は次のようなものです:

6.2.1 コンシューマがユーザをサービスプロバイダに案内する

リクエストトークンをアクセストークンに変換できるようにするために、 コンシューマは、ユーザをサービスプロバイダに送って同意を得るようにしなければなりません(MUST)。 サービスプロバイダの認証 URL に次のパラメータを付けた形で HTTP GET リクエストが 起こるように、コンシューマは URL を組み立てます。

oauth_token
OPTIONAL。前段階で取得したリクエストトークン。サービスプロバイダは、 このパラメータを必須(REQUIRED)パラメータであるとしても構いませんし、 この値がない場合を受け入れて、無い場合にユーザにそれを手動で入力するように促しても構いません。
oauth_callback
OPTIONAL。ユーザの承認が完了した後に、サービスプロバイダがユーザを リダイレクトするのに使う URL を、コンシューマが指定しても構いません(MAY)。
追加パラメータ
サービスプロバイダで定義されている任意の追加パラメータ

リクエスト URL が構築されると、コンシューマはユーザのブラウザを使ってユーザをその URL に リダイレクトします。 コンシューマが HTTP リダイレクションができない場合は、コンシューマは構築した URL に 行くようにユーザに指示しても構いません(SHALL)。

注: コンシューマが携帯デバイスやセットトップボックスで動作していることを、 サービスプロバイダが知っている場合は、サービスプロバイダはユーザ承認 URL や リクエストトークンが手動入力するのに適しているものであるようにすべきです(SHOULD)。

6.2.2 サービスプロバイダはユーザを認証して、同意を取る

サービスプロバイダはユーザの ID を確認して、詳細についての利用同意を確認します。 OAuth仕様では、サービスプロバイダがユーザをどう認証するかは定義していません。 しかし、必須の (REQUIRED) 手順は定義しています。

  • 同意を確認する前に、サービスプロバイダはユーザの ID を確認しなければなりません(MUST)。 ユーザがログインしていない場合は、ログイン画面を表示してもかまいません(MAY)。
  • サービスプロバイダは、コンシューマがアクセスを要求している(コンシューマデベロッパが登録した通りの) 情報をユーザに提示します。この情報にはアクセスする期間と保護リソースが含まれます。 この情報にはサービスプロバイダ特有の他の詳細な情報を含んでいてもかまいません(MAY)。
  • ユーザになりかわって保護リソースにコンシューマがアクセスできるように、ユーザは承認するか拒否するかを サービスプロバイダに伝えます。 コンシューマのアクセスをユーザが拒否した場合、サービスプロバイダは保護リソースへの アクセスを許してはいけません(MUST NOT)。

ユーザに、コンシューマキーに基づいて得られたコンシューマの識別情報を提示する場合、 サービスプロバイダはコンシューマの本当の識別情報を取得することができないかどうかをユーザに 知らせなければなりません(MUST)。 サービスプロバイダがこの識別情報がどの程度確かなものかを保障するかは、この仕様の範囲外です。

6.2.3 サービスプロバイダがユーザをコンシューマに案内する

ユーザの認証をしてコンシューマアクセスがサービスプロバイダに認められた後、 リクエストトークンが承認されてアクセストークンに変換できる状態になったことを コンシューマは知らせられなければなりません(MUST)。 ユーザが拒否した場合、コンシューマはリクエストトークンが破棄されたことを通知されてもかまいません(MAY)。

コンシューマが oauth_callback (「コンシューマがユーザをサービスプロバイダに案内する」で記載) を使って callback URL を指定してきた場合、サービスプロバイダは HTTP GET リクエストの URL を構成し、 次のパラメータをつけてユーザのウェブブラウザをリダイレクトします。

oauth_token
ユーザが承認あるいは拒否したリクエストトークン

callback URL はコンシューマがつけたクエリーパラメータを含めてもかまいません(MAY)。 サービスプロバイダはこれらを変更することなく、既存のパラメータにそのまま oauth_token パラメータを 連結しなければなりません(MUST)。

callback URL がない場合は、ユーザがコンシューマに認証が完了したことを手動で伝えなければならないことを、 サービスプロバイダはユーザに提示しなければなりません。

6.3 アクセストークンの取得

コンシューマは、リクエストトークンを保護リソースにアクセスすることのできるアクセストークンに変換します。 アクセストークンの取得はつぎのステップを踏みます。

6.3.1 コンシューマがアクセストークンを要求する

リクエストトークンとトークンシークレットは、アクセストークンとトークンシークレットと 交換されなければなりません(MUST)。

アクセストークンを要求するには、コンシューマはアクセストークン URL に HTTP リクエストを発行します。 サービスプロバイダのドキュメントでは、このときのリクエストで使われる HTTP メソッドを指定しなければなりませんが、 HTTP POST が推奨されています(RECOMMEND)。 リクエストは「リクエストの署名」の方法に従って署名されていなければならず(MUST)、 次のパラメータを含んでいます。

oauth_consumer_key
コンシューマキー
oauth_token
以前取得したリクエストトークン
oauth_signature_method
コンシューマがリクエストを署名する方法
oauth_signature
「リクエストの署名」の方法で得られる署名
oauth_timestamp
詳細は「Nonce とタイムスタンプ」を参照
oauth_nonce
詳細は「Nonce とタイムスタンプ」を参照
oauth_version
OPTIONAL。もしあれば、その値は 1.0 でなければなりません(MUST)。 もしこのパラメータがない場合は、サービスプロバイダはプロトコルバージョンは 1.0 であると 仮定しなければなりません(MUST)。1.0 でない場合の、サービスプロバイダからのレスポンスについては未定義です。

アクセストークンをリクエストする際には、サービスプロバイダ特有の追加パラメータをつけてはいけません。 これはトークンに紐付くすべての情報が、ユーザの同意を取る前に提示されているようにするためです。

6.3.2 サービスプロバイダがアクセストークンを承認する

サービスプロバイダは次のことを確認しなければなりません(MUST)。

  • リクエストについている署名の検証
  • リクエストトークンが既にアクセストークンと交換されていないかどうか
  • リクエストトークンがコンシューマキーと合致するか

もし確認が取れれば、サービスプロバイダはアクセストークンとトークンシークレットを生成して、 「サービスプロバイダ応答パラメータ」で記載されているように、HTTP レスポンスボディに格納して送り返します。 アクセストークンとトークンシークレットはコンシューマに保存され、保護りソースに署名する際に使われます。 応答には次のパラメータが含まれます。

oauth_token
アクセストークン(訳注:ここはリクエストトークンではなくアクセストークンです。oauth_token という同じ名前を使うので、混乱しないように注意してください。)
oauth_token_secret
トークンシークレット
追加パラメータ
サービスパラメータの定義している任意の追加パラメータ

確認が取れていなかったり、それ以外の理由により拒否された場合は、サービスプロバイダは 「HTTP レスポンスコード」で定義されている適切な応答コードを返すべきです(SHOULD)。 「サービスプロバイダ応答パラメータ」で定義されているように、リクエストが失敗した理由についての より詳細な情報を HTTP レスポンスボディ中に含めてもかまいません(MAY)。

7 コンシューマが保護リソースにアクセスする

アクセストークンとトークンシークレットを無事受け取った後、コンシューマはユーザに成り代わって 保護リソースにアクセスできるようになります。 リクエストは「署名リクエスト」ごとに署名しなければならず(MUST)、次のパラメータを含んでいなければなりません。

oauth_consumer_key
コンシューマキー
oauth_token
アクセストークン(訳注:ここはリクエストトークンではなくアクセストークンです。oauth_token という同じ名前を使うので、混乱しないように注意してください。)
oauth_signature_method
コンシューマがリクエストに署名する方法
oauth_signature
「リクエストの署名」で定義されている署名
oauth_timestamp
詳細は「Nonce とタイムスタンプ」を参照
oauth_nonce
詳細は「Nonce とタイムスタンプ」を参照
oauth_version
OPTIONAL。もしあれば、その値は 1.0 でなければなりません(MUST)。 もしこのパラメータがない場合は、サービスプロバイダはプロトコルバージョンは 1.0 であると 仮定しなければなりません(MUST)。1.0 でない場合の、サービスプロバイダからのレスポンスについては未定義です。
追加パラメータ
サービスプロバイダの定義する任意の追加パラメータ

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)。

(訳注:HMAC-SHA1, RSA-SHA1, PLAINTEXT の間の大きな違いは、鍵の使い方にあります。 それぞれ共有鍵・対象鍵方式、公開鍵・非対称鍵方式、鍵なしになります。)

9.1 署名ベース文字列

署名ベース文字列は、リクエストの要素を復元できる形でひとつの文字列に連結したものです。 この文字列は hashing や署名アルゴリズムの入力値として使われます。 HMAC-SHA1 署名方法を標準的な方法として、 署名を生成する際に署名ベース文字列を使う例を示します(訳注:付録にて)。 署名ベース文字列を構築する前に、全てのリクエストパラメータは 「パラメータエンコード」に記載されている方法で、エンコードされていなければなりません。

9.1.1 リクエストパラメータの正規化

リクエストパラメータは収集、ソート、正規化されてから、文字列に連結されます:

  • OAuth HTTP 承認ヘッダの realm パラメータを除いたパラメータ
  • HTTP POST リクエストボディ中のパラメータ(Content-type が application/x-www-form-urlencoded のもの)
  • URL のクエリーパートに追加されている HTTP GET パラメータ(RFC3986 section 3 定義)

oauth_signature パラメータは除外されていなければなりません。

パラメータは次の手順でひとつの文字列に正規化されます。

  1. パラメータはパラメータ名でソートされます。ソート順は辞書的なバイト値順です。 同じパラメータ名を使うものが二つ以上ある場合は、値の順番でソートします。たとえば
    a=1, c=hi%20there, f=25, f=50, f=a, z=p, z=t
  2. パラメータはソートした順番に従ってひとつの文字列に連結されます。それぞれのパラメータについて、 パラメータ名と値は '=' 文字(ASCII code 61)で区切られいてます。値が空でも '=' 区切りです。 パラメータ名-値のペア同士の間は '&' 文字 (ASCII code 38) で区切られます。たとえば:
    a=1&c=hi%20there&f=25&f=50&f=1&z=p&z=t

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)で区切られていなければなりません。

  1. リクエストが送信された HTTP リクエストメソッド。値は大文字でなければなりません。たとえば HEAD, GET, POST などです。
  2. Section 9.1.2 で記載したリクエスト URL
  3. Section 9.1.1 で記載した正規化したリクエストパラメータ

署名ベース文字列の例については Appendix A.5.1 を参照してください。

9.2 HMAC-SHA1

HMAC-SHA1 署名方法では、RFC2104 で定義されている HMAC-SHA1 署名アルゴリズムを使い、 RFC2104 での text は署名ベース文字列で、key はコンシューマシークレットと トークンシークレット(訳注:oauth_token_secret)を (まずパラメータエンコーディングしてから)'&' 文字 (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-SHA1

RSA-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 PLAINTEXT

PLAINTEXT 方法では、セキュリティ的な保護はされませんので、HTTPS といったセキュアな 通信路上で使用すべきです(SHOULD)。署名ベース文字列は使いません。

9.4.1 署名の生成

oauth_signature はコンシューマシークレットとトークンシークレットを 「パラメータエンコード」して '&' 文字(ASCII code 38)区切りで連結したものです。 空でも連結します。 (訳注:最終的にはパラメータの値として転送する際に) 得られた結果は再度パラメータエンコードしなければなりません(MUST)。

次の例ではコンシューマキーが djr9rjt0jd78jf88 のときに、3 つの異なるトークンシークレットについて oauth_signature の値が、それぞれどのようになるかを示しています。 (訳注:GET を使う場合は、クエリーストリングにこの文字列がそのまま現れることになります。)

jjd999tj88uiths3
oauth_signature=djr9rjt0jd78jf88%26jjd999tj88uiths3
jjd99$tj88uiths3
oauth_signature=djr9rjt0jd78jf88%26jjd99%2524tj88uiths3
Empty
oauth_signature=djr9rjt0jd78jf88%26

9.4.2 署名の検証

サービスプロバイダは署名の値をコンシューマシークレットとトークンシークレットに分解して、 手元に保存されているシークレットと一致するかを検証します。

10 HTTP レスポンスコード

この章の内容はリクエストトークンとアクセストークンリクエストにのみ適用されます。 一般的には、サービスプロバイダは RFC2616 Section 10 で定義されているレスポンスコードを使うべきです(SHOULD)。 サービスプロバイダがコンシューマのリクエストを拒否する際には、HTTP 400 Bad Request あるいは HTTP 401 Unauthorized のレスポンスを返すべきです(SHOULD)。

  • HTTP 400 Bad Request
    • Unsupported parameter
    • Unsupported signature method
    • Missing required parameter
    • Duplicated OAuth Protocol Parameter
  • HTTP 401 Unauthorized
    • Invalid Consumer Key
    • Invalid / expired Token
    • Invalid signature
    • Invalid / used nonce

Appendix

略。

11 参考文献

  • [NIST] National Institute of Standards and Technolog, NIST., “NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1.”
  • [RFC2045] Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” RFC 2045.
  • [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104.
  • [RFC2119] Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119.
  • [RFC2606] Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” RFC 2606.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” RFC 2616.
  • [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617.
  • [RFC3447] Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” RFC 3447.
  • [RFC3629] Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” RFC 3629.
  • [RFC3986] Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” RFC 3986.
  • [SHA1] De Canniere, C. and C. Rechberger, “Finding SHA-1 Characteristics: General Results and Applications.”

著者のアドレス

OAuth Core Workgroup Email: spec@oauth.net

訳に関する問い合わせは kwi@i-revo.co.jp にお願いします。


添付ファイル: filediagram.png 926件 [詳細]

リロード   新規 下位ページ作成 編集 凍結 差分 添付 コピー 名前変更   ホーム 一覧 検索 最終更新 バックアップ リンク元   ヘルプ   最終更新のRSS
Last-modified: Wed, 24 Sep 2014 17:02:54 JST (1061d)

© 2006-2008 Internet Revolution