[29] OAuth 1.0 の規定に従い要求引数を追加した HTTP要求を、 認証された要求authenticated requestといいます。 認証された要求には OAuth 1.0 による要求URLと引数の署名が含まれており、 鯖は正しいクライアントによって生成された要求であるかを検証できます。

[48] OAuth 1.0 では、最初の資源所有者に認可を求めアクセストークンを得る手続きとそれ以後のアクセストークンを使って Web API にアクセスする段階の両方で認証された要求を使います。 稀に本来の OAuth 1.0 以外でも本方式を流用していることがあります。

[49] 認証された要求は、クライアントが鯖に送信する際に署名するものです。 逆に鯖からクライアントに送信する応答では、これに類するものは使いません。 またクライアントと資源所有者や鯖と資源所有者とのやり取りでも、使いません。

仕様書

意味

[2] 認証された要求authenticated requestには、 クライアントを表すクライアントcredentialsと、 資源所有者を表すトークンcredentialsを含めます >>1。

[3] 認証された要求の作成に当たっては鯖の設定に関する事前の知識が必要です。 クライアントが鯖の要求する設定をどう発見するかは OAuth 仕様の範囲外とされています。 >>1

[30] 具体的には、どの署名方式に対応しているかを知っている必要があります。

作成

[7] 認証された要求は、HTTP要求に次のように引数を加えて作成します。

  1. [8] 次の引数を用意します。
    [9] oauth_consumer_key
    クライアントcredentialsの識別子 >>6。
    [10] oauth_token
    資源所有者を関連付けるためのトークンの値。 資源所有者と関連付けない場合には、省略して構いません。 >>6
    [11] oauth_signature_method
    クライアントが使う署名方式の名前 >>6。
    [12] oauth_timestamp
    タイムスタンプ。 ただし oauth_signature_method=PLAINTEXT なら、 省略して構いません。 >>6
    [13] oauth_nonce
    nonce 値。 ただし oauth_signature_method=PLAINTEXT なら、 省略して構いません。 >>6
    [14] oauth_version
    1.0。 省略しても構いません。 >>6
    [40] oauth_body_hash
    指定するべき場合には、 仕様に従い計算した値 >>39。 (oauth_body_hash 参照。)
  2. [15] 用意した引数を、転送方式のいずれかにより要求に追加します。 >>6
  3. [16] oauth_signature の値を計算します。 >>6
  4. [17] oauth_signature 引数を >>15 で選択した転送方式により要求に追加します。 >>6

[42] oauth_signature_method=RSA-SHA1 では、 xoauth_signature_publickey 引数や xoauth_public_key 引数も指定されることがあります。

[32] 一時credentials要求では、クライアントが鯖に認証された要求を送信しますが、 この時はクライアントcredentialsだけ使い、トークンcredentialsは指定しません >>31。

[5] トークン要求では、クライアントが鯖に認証された要求を送信しますが、 この時はクライアントcredentialsと共に (トークンcredentialsのかわりに) 一時credentialsを使います >>4。

[36] xAuth では oauth_token を使わず、 HMAC-SHA1 計算時のトークン共有秘密は空文字列とします >>35。

[33] Google の 2-legged OAuth では、 oauth_token を使わず、代わりに xoauth_requestor_id を使うことになっていました。 ただし xoauth_requestor_id は Authorization: ヘッダーではなく、 URL query に指定します。 >>34

[38] Bitbucket や Mobage >>47 の 2-Legged OAuth では、 oauth_token とトークン秘密を使わないことで、 consumer として操作することを表すようです。

[44] mixi から外部アプリケーションサイトへの署名つき要求は、 oauth_token を使わず、 oauth_signature_method=RSA-SHA1 により公開鍵方式で署名しています >>43, >>45, >>46。

検証verify

[19] 鯖は、認証された要求を受信したら、次のように妥当性検証validateしなければなりません。

[41] oauth_body_hash 引数が適用される場合には、 独自に計算し、指定された値と比較します。あるいは禁止されている場合に oauth_body_hash が指定されていないことを確認します。 >>39

oauth_body_hash も参照。

[24] この検証verificationに失敗した場合には、 適切な状態符号で応答を返すべきです。 payload body に拒絶の理由の詳細を含めて構いません。 >>18

[27] oauth_timestamp がある程度古ければ、 鯖は拒絶しても構いません。

[25] 未対応の引数、未対応の署名方式、引数の不足、 OAuth 引数の重複が見られる時は、 400 応答を返すべきです >>18。

[26] 非妥当なクライアントcredentials、 非妥当なトークンや満期したトークン、 非妥当な署名、 非妥当な nonce や使用済みの nonce の時は、 401 応答を返すべきです >>18。

[37] OAuth 1.0 本体仕様としてはエラー時の応答についてこれ以上の詳細は規定していません。 OAuth Problem Reporting Extension は報告方法を規定しており、 実装によってはこれに対応しています。

関連

[28] 署名方式、要求引数も参照。

[50] OAuth 2.0 では認証された要求に相当する概念はなくなっています。

[51] AWS4 も同趣旨の署名を行うものですが、まったく互換性はありません。