The method to update your application from OAuth Core 1.0 to 1.0a

null Y

米Yahoo!がOAuth Core 1.0 Revision Aに対応しました。

説明は省略して、結局今までOAuthのConsumerを実装してた人はどうすればいいのかをざっくりまとめておきます。

以下の4つの対応が必要です。

  1. Request Token取得要求時にoauth_callbackパラメータを付加
  2. 認可要求のためのリダイレクトURLからoauth_callbackパラメータを削除
  3. 認可後の認可応答に含まれるoauth_verifierパラメータを取得
  4. Access Token取得要求時にoauth_verifierパラメータを付加

YDN上のドキュメントhttp://developer.yahoo.com/oauth/guide/oauth-auth-flow.htmlの内容を引用して説明します。

■ Request Token取得要求時にoauth_callbackパラメータを付加

ドキュメントの"Get a Request Token (get_request_token)"の項目を見てください。

oauth_callback :
Yahoo! redirects Users to this URL after they authorize access to their private data.
If your application does not have access to a browser, you must specify the callback as oob (out of bounds).

今まで認可要求時にパラメータとして付加していたoauth_callbackパラメータをRequest Token取得時のパラメータに含んであらかじめ連絡しておきます。Yahoo!は発行したRequest Tokenと紐づけて取っておくのでしょう。
こんな感じになります。

https://api.login.yahoo.com/oauth/v2/get_request_token?oauth_version=1.0
&oauth_nonce=dbf0f4981ce6a96fc82d75284972ae5a
&oauth_timestamp=1242838649
&oauth_consumer_key=(ConsumerKey)
&oauth_callback=http%3A%2F%2Fr-weblife.sakura.ne.jp%2Foauthviewer%2F%3Fauth%3D2
&oauth_signature_method=HMAC-SHA1
&oauth_signature=PSObtgVV1%2FiWAnn7dbrMKPYfkVg%3D

※リクエストパラメータのときのSyntaxって何使えばいいんですか？

クライアントアプリの場合は、"oob"と指定する必要があります。今回は割愛します。
成功すると、レスポンスは以下のようになります。

oauth_token=kcwwcga
&oauth_token_secret=6008176e3b523533c90de9e57f5981915b2114f7
&oauth_expires_in=3600
&xoauth_request_auth_url=https%3A%2F%2Fapi.login.yahoo.com%2Foauth%2Fv2%2Frequest_auth%3Foauth_token%3Dkcwwcga
&oauth_callback_confirmed=true

"oauth_callback_confirmed"というパラメータがあります。
しかし、これは絶対trueです。falseが返る状況は存在しなくて、戻り先不正の場合はエラーメッセージでその旨が伝えられると思います。

oauth_callback_confirmed=true :
This parameter confirms that you are using OAuth 1.0 Rev. A. This parameter is always set to true.

■ 認可要求のためのリダイレクトURLからoauth_callbackパラメータを削除

上述したとおり、あらかじめ戻り先URLを伝えてありますので、認可要求の際のリダイレクトURLにはRequest Tokenのみを含みます。

https://api.login.yahoo.com/oauth/v2/request_auth?oauth_token=kcwwcga

■ 認可後の認可応答に含まれるoauth_verifierパラメータを取得

oauth_verifierパラメータは、Request Tokenを発行したUserとブラウザで認可処理を行ったUserが同一であることを確認できるためのパラメータです。

http://r-weblife.sakura.ne.jp/oauthviewer/?auth=2&oauth_token=kcwwcga&oauth_verifier=dmrssu

■ Access Token取得要求時にoauth_verifierパラメータを付加

リクエストはこのような感じになります。

https://api.login.yahoo.com/oauth/v2/get_token?oauth_version=1.0
&oauth_nonce=1d6b3393bd7aa54115ad13c7a9ac4ee8
&oauth_timestamp=1242840089
&oauth_consumer_key=(ConsumerKey)
&oauth_token=kcwwcga
&oauth_verifier=dmrssu
&oauth_signature_method=HMAC-SHA1
&oauth_signature=IYWErt%2BRX3AfI7%2B2ZhZzKpHTZns%3D

レスポンスは今まで通りです。

■ まとめ

今回の改修は、oauth_verifierという新しいパラメータが出てくること以外はライブラリなどを使えばパラメータの追加などは容易にできるので、"使ってるライブラリが対応するまでUpdateできないー"なんて状態にはならないと思います。

そして、最後に"結局セキュリティ的に何が変わったのか"についてですが、Rev Aでは2者間をつなぐデータが以下のようになります。

  1. (認可前)Consumer vs SP : Request Token
  2. (認可前)Consumer vs User : Request Token,独自Session
  3. (認可後)User vs SP : Request Token,oauth_verifier
  4. (認可前)Consumer vs User : Request Token,oauth_verifier,独自Session
  5. (認可後)Consumer vs SP : Request Token,oauth_verifier

OAuth Core 1.0におけるセキュリティの問題は、2,3,4の処理が同一ユーザーにより行われたことを確認できなかったことでした。
OAuth Security Issue - r-weblife
Rev Aでは、oauth_verifierパラメータにより3,4の処理を行ったユーザーの同一性が確認できます。

あとは、"ソーシャルエンジニアリングによる同意させられ"の原因だったoauth_callback改ざんのリスクをつぶしたというところでしょうか。
他のSPがRev Aに対応するのはいつかわかりませんが、ディベロッパーのみなさまの準備の参考になればと思います。

今回の実装にあたっては、OAuthパラメータ確認用に作ったoauthviewerというツール？を使いました。よろしければ使ってみてください。