OAuth Echo
- ユーザー — 特定の認可済み X アプリケーションを通じて X を利用しているユーザー
- コンシューマー — サードパーティのメディアプロバイダ（例: 写真共有サイト）とやり取りしようとしている X アプリケーション
- デリゲーター — サードパーティのメディアプロバイダ
- サービスプロバイダ — いわゆる X 本体
x-auth-service-provider— 実質的には、アイデンティティ委譲を送信すべきレルムです。X の場合はこれを https://api.x.com/1.1/account/verify_credentials.json に設定します。iOS 5 ベースの X 連携では、この URL に追加のapplication_idパラメータを付与します。このパラメータも、x-verify-credentials-authorizationで使用されるoauth_signatureの計算に利用されます。x-verify-credentials-authorization— コンシューマーは、OAuth を使用して HTTP ヘッダーで https://api.x.com/1.1/account/verify_credentials.json を呼び出せるように、必要な OAuth パラメータをすべて作成する必要があります（例:OAuth oauth_consumer_key=”...”, oauth_token=”...”, oauth_signature_method=”...”, oauth_signature=”...”, oauth_timestamp=”...”, oauth_nonce=”...”, oauth_version=”...”のような形式）。
oauth_timestamp がまだ有効である時間内に、一連のトランザクション全体が完了する必要があることに注意してください。
別の方法として、これら 2 つのパラメータをヘッダーではなく POST のボディ内で x_auth_service_provider と x_verify_credentials_authorization として送信することもできます。この場合、OAuth シグネチャのベース文字列に、パラメータをエスケープしたうえで含めることを忘れないでください。これは、任意のリクエストでパラメータをエンコードする場合と同様です。可能な限り処理を分離しておくために、HTTP ヘッダーを使用するのが最善です。
この時点でのデリゲーターの目的は、メディアを保存する前に、ユーザーが自称どおりの人物であることを検証することです。デリゲーターは、upload メソッド経由で上記のすべてのデータを受け取ったら、画像を一時的に保存し、x-auth-service-provider ヘッダーで指定されたエンドポイント（この場合は https://api.x.com/1.1/account/verify_credentials.json）への呼び出しを構築する必要があります。その際、コンシューマーが x-verify-credentials-authorization ヘッダー内で提供したものと同じ OAuth 認証ヘッダーを使用します。
OAuth Echo のベストプラクティス
x-auth-service-provider によって提供される URL を使用して照会を行い、ハードコードされた値は 使用しないでください。たとえば Apple iOS は、すべての OAuth リクエストに追加の application_id パラメータを付加し、このパラメータは OAuth Echo の各段階で保持されている必要があります。
OAuth 認可の部分では、x-verify-credentials-authorization のヘッダー値を取得し、サービスプロバイダーへのリクエストでは、その値を Authorization ヘッダーに設定します。念のため、x-auth-service-provider 内の値が期待どおりであることを確認してください。
- Service Provider が HTTP 200 を返した場合は問題ありません。Delegator は画像を永続的に保存し、URL を生成して返す必要があります。
- Service Provider が HTTP 200 を返さなかった場合は、画像を破棄し、Consumer にエラーを返してください。