署名 (OAuth 1.0)

署名方式 (HTTP)

[12] OAuth 1.0署名を計算する方式を署名方式 (signature method) といいます。 クライアントは選択した署名方式oauth_signature_method 引数に、計算した署名oauth_signature 引数に指定することになっています。署名を確認し、 正当なクライアントからの認証された要求であるかを調べることになっています。

仕様書

署名

[8] 認証された要求には2組のcredentialsが含まれますが、 認証検証して認可されていないアクセスを防ぐために、 クライアントは自身が credentials の正当な所有者であることを示す必要があります。 このために credentials共有秘密または RSA鍵を使って署名します。 >>7

署名方式

[9] 署名方式 (signature method) には次のものがあります。

[10] OAuth 仕様としてはどの署名方式も必須とはなっていません >>7

[13] HMAC-SHA1 を使うことが多く、それ以外を使うことはあまりないようです。

[27] Twitter >>26はてな >>28 など >>29, >>30, >>31, >>34, >>35, >>38, >>41, >>51HMAC-SHA1 に対応しています。

[25] GoogleHMAC-SHA1RSA-SHA1 に対応していました >>24

[37] Open Bank projectHMAC-SHA1HMAC-SHA256 (独自) に対応しています >>36

[45] Adobe Digital Publishing Suite Folio Producer API は HMAC-SHA256 (独自) に対応しているようです >>44

[47] VitaDockHMAC-SHA256 (独自) に対応しています >>46, >>48

[50] WooCommerceHMAC-SHA1HMAC-SHA256 (独自) に対応しています >>49

[40] DropboxPLAINTEXT に対応しています >>39HMAC-SHA1 にも対応していると推測されます。

[43] EvernoteHMAC-SHA1PLAINTEXT に対応しています >>42

[11] は独自の署名方式を使うことができます >>7

[33] 新しい署名方式を規定する際は、 oauth_body_hashハッシュアルゴリズムを規定するべきです >>32

oauth_signature 引数

[3] 認証された要求oauth_signature 引数は、署名の計算結果の値を表します。

oauth_signature_method 引数

[2] 認証された要求oauth_signature_method 引数は、 クライアントが使用する署名方法を表します。

[4] この値が PLAINTEXT であるか否かにより、 oauth_timestamp, oauth_nonce が必要か否かが変わります。

処理

[6] 認証された要求も参照。

実装上の困難

[14] 署名OAuth 1.0 の中で最も複雑で実装しづらく、嫌われていました。 OAuth 2.0 では TLS を必須とすることで署名を除去しています。

[15] 署名は技術的にはそれほど難解ではなく、特に署名アルゴリズムの実装を既存のライブラリーに委ねている場合には、 クライアントが自前で行わなければならない処理はほとんどありません。 それでも実装しづらいのは、何重にも符号化を重ねていること、 そのパーセント符号化にバリエーションが多く誤った選択をしても気づきにくいこと、 署名対象となる HTTP要求の各構成部分 (URL の各部や引数) の扱いが既存のライブラリーや WAF 等で様々で、それぞれが独自の符号化や変換、 独自データ構造での保持などを行っていて実際に送信される値を取得するのが難しかったり、 不可能だったりすることなど、様々な罠があります。

[16] 例えばWAF によって復号された対象URLではなく、 要求対象として指定されたパーセント符号化を保持したURLが必要です。

[18] 例えば逆串の裏側で動作するは、クライアントが指定した元の Host: ヘッダーの値にアクセスできる必要があります。

[17] 例えばクライアントは入力として与えられた対象URLquery が含まれていれば、正しく復号して再度符号化して署名対象としなければなりません。

[20] 例えばが使う WAF によっては multipart/form-dataapplication/x-www-form-urlencodedpayload body を透過的に扱い、署名の計算に必要な後者で指定された引数のみを取り出すことができないかもしれません。

[21] 例えばHTTP鯖アプリケーションサーバー、 その中間で動作するミドルウェアといったソフトウェア部品で構成される場合 (具体的には WSGIPSGI などの場合) で、ミドルウェア署名の計算に必要な対象URLapplication/x-www-form-urlencoded を破壊的に操作する場合、 アプリケーションサーバーは正しく署名を計算できないかもしれません。 アプリケーションサーバーミドルウェアの開発者が異なる場合やミドルウェアが条件 (URL のパターンや本番サーバーか開発サーバーの違いなど) 次第で適用されたりされなかったりする場合、 アプリケーションサーバー側の開発者が署名の計算に失敗する理由を特定するのは困難かもしれません。

[19] 署名要求引数を必要としており、要求URL の一部である URL queryapplication/x-www-form-urlencoded payload body の生成とも関係しています。そのため、狭義の HTTP要求の生成処理と OAuth 1.0 の処理を完全に分離することが難しく、 HTTP 処理ライブラリーのモジュール化設計に悪い影響を与えています。 これも OAuth 1.0、とりわけその署名が嫌われる一因となります。

[22] 署名が正しく処理されるためにはクライアントの両方がすべての生成過程を正しく実装する必要があり、 通常は互いがどのように署名を計算したかを知ることができません。 このことが署名の実装をより困難にしています。

[23] 例えばが使用している署名計算ルーチンが引数非ASCII文字が含まれる場合だけ文字コードの扱いに不具合があるとします。 その引数非ASCII文字が含まれることが滅多になければ、 の開発者はその不具合に気づかないかもしれません。 クライアントが正しく署名を計算していると、当然ながら両者の署名は一致しませんが、 クライアント側の開発者がこの不具合に気づくのは困難です (この例ではクライアント側が非ASCII文字を含めることも滅多にないのでしょうから、クライアント側の利用者からの報告で開発者が問題に気づいても、非ASCII文字が原因と特定することさえ難しいかもしれません)。 の開発者としても、署名の不一致が自身の不具合によるものかクライアントの問題によるものか判断するのは困難です。