最近にわかにTwitter APIのxAuth認証が話題になっています。これは主にデスクトップアプリケーション向けに用意される認証方式で、簡潔に言うと「Webブラウザで認証画面を開く必要のないOAuth」といったところです。
従来のOAuth認証ではまずアプリケーション（OAuthコンシューマ）がTwitterに接続してRequest Tokenを取得し、認証画面を開いてRequest Tokenを承認させ、承認されたRequest Tokenを使ってAccess TokenとToken Secretを取得することによって各APIにアクセスできるようになります。しかしこれはアプリケーション側の実装が複雑になる上、デスクトップアプリケーションの場合はわざわざWebブラウザへ切り替えなければならず（ブラウザを内包するものもありますが）、ユーザにとっても面倒なものです。
そこで提案されたのがxAuthで、これはRequest Tokenの取得と認証という手順を省きます。アプリケーションはユーザからユーザ名とパスワードを受け取り、それを用いてTwitterに問い合わせることでAccess TokenとToken Secretを直接取得することが出来ます。xAuthを用いればアプリケーション側の実装は簡単になり、ユーザもわざわざWebブラウザを使って認証する必要がなくなります。
OAuthにくらべてアプリケーション側もユーザ側も作業を簡略化できるxAuthですが、当然デメリットがあります。OAuthの利点の一つ、ユーザがアプリケーションにパスワードを預けなくても良いという点が完全に失われます。xAuthでは一度Access Tokenを取得してしまえばそれ以降パスワードは使用しませんが、アプリケーションがパスワードをちゃんと破棄したかどうかはユーザにはわかりません。もしかしたらこっそりパスワードを保存していて、裏でこそこそと悪さをしてしまうかもしれないのです。つまり、Basic認証によるAPI利用の欠点（のひとつ）をxAuth認証も抱えているわけです。（まあ、認証したらすぐにパスワードを変えちゃうってのもアリですが、Twitterのパスワード変更は色々と面倒なので…）
パスワードを預けるという性質上、Webアプリケーションでは採用の余地はありません。素直にOAuthを使いましょう。必然的に、xAuthを採用できるのは（精神衛生的にパスワードを預けやすい）デスクトップアプリケーションになります。毎回パスワードをほぼ平文で垂れ流すBasic認証よりは間違いなくセキュアなので、ユーザの利便性を考えるなら採用を検討する価値は大いにあります。
Twitter APIのBasic認証は今年6月に廃止予定で、Basic認証を利用しているアプリケーションはこれに対処する必要がありますが、xAuthを使用することが出来ればアプリケーションへの変更がより少なくて済むんじゃないでしょうか。
