OAuthにくらべてアプリケーション側もユーザ側も作業を簡略化できるxAuthですが、当然デメリットがあります。OAuthの利点の一つ、ユーザがアプリケーションにパスワードを預けなくても良いという点が完全に失われます。xAuthでは一度Access Tokenを取得してしまえばそれ以降パスワードは使用しませんが、アプリケーションがパスワードをちゃんと破棄したかどうかはユーザにはわかりません。もしかしたらこっそりパスワードを保存していて、裏でこそこそと悪さをしてしまうかもしれないのです。つまり、Basic認証によるAPI利用の欠点（のひとつ）をxAuth認証も抱えているわけです。（まあ、認証したらすぐにパスワードを変えちゃうってのもアリですが、Twitterのパスワード変更は色々と面倒なので…）
The only problem is that Yahoo quietly pushed through an extension to OAuth called the OAuth Session Extension. This was all done publicly but it involves some major changes to OAuth token management, which is the exact thing that has been hardest for people to understand about OAuth in the first place.
Step 8.
Post a new message:
http.setURL('https://www.yammer.com/api/v1/messages') http.setHeaderField('Authorization', oauth_headers('BDzef0Gju2zIDQLnh33UKg','aewBdSXbnPtwywZISFxmoxgp3XN8lyn2HGV2DREZt7g', null)) http.addParameter('body', 'test message') http.setMethod(POST)When using PLAINTEXT signature method, the parameters you add to a POST do not affect the signature. This is not true when using HMAC-SHA1. PLAINTEXT is much easier to debug and since yammer uses https, it's safe to use PLAINTEX
Yammerはhttpsを使っているのでPLAINTEXTを安全に使えるよ。
デバッグするならPLAINTEXTがだいぶ楽です。
Plaxo is one of the earliest adopters of OpenID, allowing their users to sign into Plaxo using an OpenID enabled account with just a couple mouse clicks. Instead of requiring first-time Plaxo users to manually verify their email address by sending a verification email, Plaxo uses OpenID Attribute Exchange to verify Yahoo! and GMail email addresses without forcing users to wait at their mailbox for the verification email to arrive. Building on their successful experience with OpenID, Plaxo is experimenting with the Hybrid Protocol: A portion of new users who sign up for Plaxo using either a GMail or Yahoo account can now sign into Plaxo with their OpenID and authorize two-way data sharing of their Contacts and Activities via the Hybrid Protocol. You can read more about how this works on the Plaxo blog.
7.1. Authorization Header Protocol parameters can be transmitted using the HTTP "Authorization" header as defined by [RFC2617] with the auth-scheme name set to "OAuth" (case-insensitive). For example: Authorization: OAuth realm="http://server.example.com/", oauth_consumer_key="0685bd9184jfhq22", oauth_token="ad180jjd733klru7", oauth_signature_method="HMAC-SHA1", oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D", oauth_timestamp="137131200", oauth_nonce="4572616e48616d6d65724c61686176", oauth_version="1.0
今回発見された脆弱性は、次の通り。攻撃者はまず一般ユーザーとして当該サービスにログイン。続いてOAuthによる認可を行うが、通常の流れと異なるのは、リクエスト・トークンとして発行されたURIを保存し、これをターゲットとなるユーザーにクリックさせるようにし向けるところだ。何らかの理由でURIをクリックしたターゲットユーザーは、正規のサービスへリダイレクトされ、データアクセスの許可を求められる。ここでターゲットのユーザーがもしOKボタンを押してしまうと、攻撃者はリクエスト・トークンを使ってOAuthの認可のプロセスを完了できてしまうという。
これらの3つのステップを結びつける唯一の要素は、承認URIとコールバックURIにおけるリクエストトークンだ。どちらについても、その呼び出しは署名されているものではなく、簡単に推測できるものだ。問題は、コンシューマに対してもプロバイダに対しても、これらの3つのステップが同一のユーザによって行われているという保証が無い、ということだ。アプリケーションは、クッキーや他のセッション管理ツールによって、最初のステップと最後のステップが同一のユーザによって行われていることを確認できるが、真ん中のステップが、最初または最後のステップと同一のものであるかどうかは確認できない。
