メインコンテンツへスキップ

署名の作成

このページでは、HTTP リクエストに対する OAuth 1.0a HMAC-SHA1 署名の生成方法について説明します。この署名は、リクエストの認可 で説明しているとおり、認可済みリクエストの一部として X API に渡すのに適しています。 署名の手順を説明するために使用するリクエストは、https://api.x.com/1.1/statuses/update.json への POST です。生のリクエストは次のようになります。
POST /1.1/statuses/update.json?include_entities=true HTTP/1.1
Accept: */*
Connection: close
User-Agent: OAuth gem v0.4.4
Content-Type: application/x-www-form-urlencoded
Content-Length: 76
Host: api.x.com

status=Hello%20Ladies%20%2b%20Gentlemen%2c%20a%20signed%20OAuth%20request%21
リクエストメソッドとURLの取得 シグネチャを生成するには、まずリクエストの HTTP メソッドと URL を特定します。これら 2 つはリクエストを作成する時点で既に把握できているため、取得は容易です。 X API へのリクエストでは、リクエストメソッドはほとんど常に GET または POST になります。
HTTP MethodPOST
ベース URL は、クエリ文字列やハッシュパラメータを除いた、リクエストの送信先となる URL です。ここで正しいプロトコルを使用することが重要なため、URL の「https://」の部分が、API に送信される実際のリクエストと一致していることを確認してください。

パラメータの収集

次に、リクエストに含まれるすべてのパラメータを収集します。これらの追加パラメータには 2 つの格納場所があり、URL (クエリ文字列の一部) とリクエストボディです。サンプルリクエストでは、両方の場所にそれぞれ 1 つのパラメータが含まれています。
POST /1.1/statuses/update.json?include_entities=true HTTP/1.1
Accept: */*
Connection: close
User-Agent: OAuth gem v0.4.4
Content-Type: application/x-www-form-urlencoded
Content-Length: 76
Host: api.x.com

status=Hello%20Ladies%20%2b%20Gentlemen%2c%20a%20signed%20OAuth%20request%21
HTTP リクエストには URL エンコードされたパラメータがありますが、生の値を取得する必要があります。リクエストパラメータに加えて、すべての oauth_* パラメータを署名に含める必要があるため、それらも収集します。以下は、リクエストの認可 からのパラメータです。
statusHello Ladies + Gentlemen, a signed OAuth request!
include_entitiestrue
oauth_consumer_keyxvz1evFS4wEEPTGEFPHBog
oauth_noncekYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg
oauth_signature_methodHMAC-SHA1
oauth_timestamp1318622958
oauth_token370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
oauth_version1.0
これらの値は 1 つの文字列にエンコードされ、後で使用します。文字列を構築する手順は非常に厳密に決められています。
  1. 署名対象となるすべてのキーと値を パーセントエンコード します。
  2. エンコード済みのキーでアルファベット順に [1] パラメータのリストをソートします [2]
  3. 各キー/値ペアについて:
  4. エンコード済みキーを出力文字列の末尾に追加します。
  5. 文字 ‘=’ を出力文字列の末尾に追加します。
  6. エンコード済み値を出力文字列の末尾に追加します。
  7. まだ残りのキー/値ペアがある場合は、文字 ‘&’ を出力文字列の末尾に追加します。  
[1] OAuth 仕様では、ソートは「辞書式順序 (lexicographically)」で行うと記載されています。これは多くのライブラリにおけるデフォルトのアルファベット順ソートです。 [2] エンコード後のキーが同じパラメータが 2 つある場合、OAuth 仕様では値を基準にソートを続けると記載されています。ただし、X は API リクエスト内の重複キーを受け付けません。   パラメータ文字列 上記で収集したパラメータに対してこれらの手順を繰り返すことで、次の「パラメータ文字列」が生成されます。
statusHello Ladies + Gentlemen, a signed OAuth request!
include_entitiestrue
oauth_consumer_keyxvz1evFS4wEEPTGEFPHBog
oauth_noncekYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg
oauth_signature_methodHMAC-SHA1
oauth_timestamp1318622958
oauth_token370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
oauth_version1.0

署名ベース文字列の作成

これまでに収集した 3 つの値を結合して 1 つの文字列にし、その文字列から署名を生成します。OAuth 仕様では、この文字列を signature base string (署名ベース文字列) と呼びます。 HTTP メソッド、ベース URL、およびパラメーター文字列を 1 つの文字列にエンコードするには、次の手順に従います。
  1. HTTP メソッドを大文字に変換し、その値を出力文字列とします。
  2. 出力文字列に ‘&’ 文字を追加します。
  3. URL をパーセントエンコードし、出力文字列に追加します。
  4. 出力文字列に ‘&’ 文字を追加します。
  5. パラメーター文字列をパーセントエンコードし、出力文字列に追加します。  
これにより、次のような signature base string (署名ベース文字列) が生成されます。
POST&https%3A%2F%2Fapi.x.com%2F1.1%2Fstatuses%2Fupdate.json&include_entities%3Dtrue%26oauth_consumer_key%3Dxvz1evFS4wEEPTGEFPHBog%26oauth_nonce%3DkYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1318622958%26oauth_token%3D370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb%26oauth_version%3D1.0%26status%3DHello%2520Ladies%2520%252B%2520Gentlemen%252C%2520a%2520signed%2520OAuth%2520request%2521
パラメーター文字列は必ずパーセントエンコードしてください。signature base string には、アンパサンド & 文字がちょうど 2 つだけ含まれている必要があります。パラメーター文字列内のパーセント % 文字は、signature base string 内では %25 にエンコードされている必要があります。

署名キーを取得する

最後に収集するデータは、リクエストを行っている X app を識別するシークレットと、そのリクエストが代行しているユーザーを識別するシークレットです。これらの値は非常に機密性が高く、絶対に他人と共有してはいけないことに注意してください。 X 上であなたの App を識別する値は consumer secret と呼ばれ、Developer Consoleapp details page で確認できます。これは、あなたの X App が送信するすべてのリクエストで同じ値になります。
Consumer secretkAcSOqF21Fu85e7zjz7ZN2U4ZRhfV3WpwPAoE3Z7kBw
アプリケーションがどのアカウントの代わりに動作しているかを識別する値は OAuth token secret と呼ばれます。この値は複数の方法で取得でき、そのすべてが obtaining access tokens で説明されています。
OAuth token secretLswwdoUaIvS8ltyTt5jkRh4J50vUPVVHtR2YPi5kE
繰り返しになりますが、これらの値はアプリケーション固有の秘密として厳重に管理する必要があります。値が漏洩した疑いがある場合は、トークンを再生成してください (このページに記載されているトークンは、実際のリクエストでは無効として扱われます) 。 これら 2 つの値は組み合わせて signing key を構成し、署名の生成に使用されます。signing key は単に、percent encoded されたトークンシークレットです。 request token を取得する場合など、一部のフローではトークンシークレットがまだ分からないことがあります。この場合、signing key は、percent encoded された consumer secret の後ろにアンパサンド文字「&」を連結したものになります。
Signing keykAcSOqF21Fu85e7zjz7ZN2U4ZRhfV3WpwPAoE3Z7kBw&LswwdoUaIvS8ltyTt5jkRh4J50vUPVVHtR2YPi5kE

シグネチャの計算

最後に、シグネチャはシグネチャベース文字列と署名キーを HMAC-SHA1 ハッシュアルゴリズムに渡して計算します。アルゴリズムの詳細は、hash_hmac 関数の説明を参照してください。 HMAC 署名関数の出力はバイナリ文字列です。これを base64 でエンコードして、シグネチャ文字列を生成する必要があります。たとえば、このページで示したシグネチャベース文字列と署名キーを入力すると、出力は 2E CF 77 84 98 99 6D 0D DA 90 5D C7 17 7C 75 07 3F 3F CD 4E となります。この値を base64 に変換したものが、このリクエストの OAuth シグネチャです。
OAuth signatureLs93hJiZbQ3akF3HF3x1Bz8/zU4=