OAuth Echoを調べたのでメモ
前々から気になっていたOAuth Echoについて調べてみました。まだ試してませんが。
そんなわけで、調べたメモを。参考資料は OAuth Echo | Twitter Developers などで。仕様としてはOAuth Echo - Identity Verification Delegation (Draftの1枚のみのようです。
use case
個人的にOAuth Echoは何だか取っ付きにくかったのですが、use caseを想定して仕様を見てみると、そんなに難しいものでも無かったです。
OAuth Echoは、Consumer(twitter clientなど)がPhoto storage(twitpicなど)に写真を投稿するときなどに使われます。
twitpicに写真を投稿するにはtwitterの認証情報が必要になりますが、twitpicは当然そんなモノ持っていません。なので、twitter clientがtwitpicに対して、どのUserが写真を投稿したいのかを伝える必要があります。
その実現のために、twitter clientはヘッダにOAuth 1.0のauthorization headerに含むような値を別のヘッダに含めてtwitpicを送ってやります。twitpicはtwitter clientからのリクエストに含まれるheaderを用いて、twitter APIのaccount/verifiy_credentialsにリクエストすることで、リクエスト元のユーザー情報を取得できるようになります。twitter clientの持つUserのaccess tokenやconsumer keyなどを使ってtwitpicが代わりにtwitterにリクエストできるということです。ここら辺が"Echo"な感じ...なんだと思いますたぶん。
OAuth Echo
OAuth Echoの登場人物は
- User
- Consumer
- Delegator
- SP
の4者です。
前提として、ConsumerはUserから認可を与えられているものとします。以下、OAuth Echoのフローです。
- ConsumerがDelegatorのendpointにリクエストします。この時、headerに"X-Auth-Service-Provider"と"X-Verify-Credentials-Authorization"を指定します。
- X-Auth-Service-ProviderにはSPにUserを特定するためのendpointを指定します。(twitterの場合はaccount/verifiy_credentials)
- X-Verify-Credentials-AuthorizationにはX-Auth-Service-Providerで指定したendpointのAPIをリクエストするのに必要な値を指定します。この値は通常ConsumerがAPIをリクエストするときに指定するAuthorization headerの値です(e.g. OAuth oauth_consumer_key="...", oauth_token="...", oauth_signature_method="...", oauth_signature="...", oauth_timestamp="...", oauth_nonce="...", oauth_version="...")。
- Delegatorはポストされたデータを一時的に保存した後、X-Auth-Service-Providerで指定されたAPIを、X-Verify-Credentials-Authorizationで指定された値をAuthorization headerに指定してリクエストします。
- SPはDelegatorのリクエストを通常のOAuth APIリクエストとして処理します。レスポンスのhttp status codeが2xxなら有効なリクエスト、そうでなければ無効なリクエストとして判断されたことになります。リクエストが成功した場合、SPはUserの情報をレスポンスに含めます。
- DelegatorはUserの情報を取得できたので、さっき一時的に保存したデータをUserと紐付けて保存することができます。
"DelegatorがUserの情報を必要とするけど、Consumerが勝手に送ってきたUser情報で保存するわけにいかないし、じゃあどうやってvalidなUser情報を取得するの?"という問題の解決策のようです。
また、リクエストするAPIに付加するsignatureはConsumerが指定しているので、Delegatorに勝手にUser情報を変更されることもありません。
ちなみに、"X-Auth-Service-Provider"と"X-Verify-Credentials-Authorization"はheaderでなくてPOSTしてもいいようです。推奨はされていないようですが。
OAuth Echo Restricted
通常のOAuth Echoよりセキュアなパターンです。
このFlowでは先程の1.で指定するheaderに加え、"x_delegator"にDelegatorの名前を指定します。
このFlowがなぜセキュアかというと、"X-Verify-Credentials-Authorization"の値(=Authorization headerの値)に含まれる"OAuth_signature"の生成にx_auth_service_providerとx_delegatorを含める必要があるので、Delegatorを完全に固定することができます(通常のOAuth Echoでは、もしDelegatorがリクエストに含まれる"X-Verify-Credentials-Authorization"の値を第三者に渡していたら、第三者がUserの情報を取得できてしまいます)。
また、SPがどのDelegator経由でリクエストが来たのかを把握できるのもポイントなのかもしれません。
