TwitterのBASIC認証廃止、企業ユーザーが知っておくべきこと

来る2010年7月1日、Twitterにいつもと違う感じを抱いたなら、BASIC認証が廃止になったことを思い出してほしい。特に、企業でTwitterを利用している場合は要注意だ。

[西尾泰三，ITmedia]

　Twitterユーザー、あるいはこのプラットフォームを利用しているデベロッパーや企業は、2010年6月30日に向けて適切な対応を図る必要がある。Twitter APIのBASIC認証が廃止されるためだ。

意外と知られていないこととして、APIの制限のほかにユーザーごとの制限があると丹羽氏。1日当たりのツイートやフォロー、ダイレクトメッセージなどに上限があるが、ダイレクトメッセージの250件／日制限に引っかかってはじめてそれに気付く企業アカウントも少なくないという

　「Twitter Development Talk（Twitter-Dev）」や「Twitter API Announcements」などではかなり前からアナウンスされていたが、2010年6月30日を最後に、Twitter APIのBASIC認証はエラーが返ってくるようになる。一見地味に映るこの出来事だが、カウントダウンサイトも用意されていることからも、与える影響は意外に広範に及ぶ。本稿では、米Twitterで国際化チームのフロントエンドエンジニアとして活躍する丹羽善将氏（@niw）の話を交えながら、この動きを取り上げる。

　Twitterを活用するためのAPI群は、基本的なAPIのほか、Search API、Streaming APIの3つに大別される。基本的なAPIとSearch APIの仕様が分かれているのは歴史的経緯によるものだが（この2つは統合が進んでいる）、これらの中には利用するために認証が必要なものがある。そこで主に用いられていた認証方式が、Base64でエンコードしたユーザー名とパスワードをHTTPリクエストと一緒に送る「BASIC認証」だった。

　BASIC認証は実装が簡単な一方で、セキュリティ面で不安がある。Twitter APIの利用についていえば、Twitterと連携した外部サービスを利用するために、Twitterのユーザー名とパスワードを第三者に渡してしまうことが特に問題となる。これはつまり、ユーザーがTwitterで行える全権限を第三者に与えてしまっているのに等しい。これを改善するものとして、ユーザー名とパスワードとはひも付かないトークンベースで、あらかじめ決められたAPIのアクセスのみを許可しようというのが「OAuth認証」だ。

　OAuth認証は、外部サービスに対して適切な利用権限を委譲するためにGoogleやTwitterなどが中心となって考案したもの。一見するとOpenIDに似ているが、OpenIDがログインや新規登録時の本人確認を外部で担保するためのものであるのに対し、OAuth認証は、外部サービスなどを通じたAPIの利用に対して制限可能な認可をトークンに対して与えるもので、リソースの種類や有効期間などを細かくコントロールできるのが特徴となる。上述したように、トークンはユーザー名やパスワードとはひも付いていないので、万が一不正利用された場合でも、そのトークンを個別に破棄すれば被害を最小限に抑えることができる。

　OAuth認証の仕組みとしては、サービスやアプリケーション（OAuthコンシューマー）がOAuthプロバイダー（ここではTwitter）に接続してRequest Tokenを取得、認証画面を開いてRequest Tokenを承認させ、そのRequest Tokenを使ってAccess TokenとToken Secretを取得することで各APIを利用する。OAuthコンシューマーにとっては、クレデンシャル（認証情報）を自前で持たずに済むので、情報セキュリティなどの観点からメリットは大きい。TwitterはBASIC認証をサポートしながらも、OAuth認証を利用した場合の3分の1にリミットレートを制限するなどして、OAuth認証への移行を推奨してきた。今回のBASIC認証廃止は、十分な周知が図られたと判断したためとしている。

　しかし、OAuth認証はその認証プロセスを見て分かるように、認証画面はOAuthプロバイダー側に遷移する（認証完了後、OAuthコンシューマーが指定したコールバックURLに遷移）ため、Webブラウザが立ち上がる。例えばiPhoneアプリの開発であれば、WebKitフレームワーク「UIWebView」のdelegateでコールバックの呼び出しをみて、そこからトークンを取得するような“行儀の悪い”方法で回避できるかもしれないが、いずれにせよモバイルアプリケーションを含めたデスクトップアプリケーションとの親和性がお世辞にも高いとはいえない認証方式だった。

　そこで2010年になって登場したのが、もう1つの認証方式である「xAuth」だ。xAuthはOAuth認証の仕組みからRequest Tokenの取得と認証を省略したもので、Webブラウザで認証画面を開く必要はない。デスクトップアプリケーションとの親和性が高い認証方式といえるが、SSLでの接続が必須である点や、利用に関して、事前にTwitterによる審査を受ける必要がある。

　丹羽氏も、「xAuthは（OAuthの）例外的な対応というのが正しい見方」としており、特殊な用途に対応するための認証がxAuthであるという見解を示している。

有名どころはOAuth／xAuthに対応予定だが注意が必要

　有名どころのTwitterクライアントやTwitterと連携するWebアプリケーションなどは、すでにOAuth認証への対応、あるいは対応予定を表明している。例えば記者も愛用しているTwitterクライアント「TweetDeck」のケースを例に考えてみよう。TweetDeckのデスクトップ版は、バージョン0.33でBASIC認証からxAuth認証に変更された（ChangelogにはOAuth認証と書かれている）。しかし、iPhone／iPad版については、xAuth認証に対応予定とあるが、現時点ではBASIC認証のままだ。仮にこのままの状態で7月を迎えたとしたら、iPhone／iPad版TweetDeckは利用できなくなる。

　このように、今回のBASIC認証廃止でエンドユーザーが注意すべきは、お使いのTwitterと連携するデスクトップアプリケーションまたはWebアプリケーションがOAuth／xAuthに対応しているかどうかだ。すでに対応しているのなら特に気にすることはないし、対応予定がないのなら、別のアプリまたはサービスに乗り換える必要が出てくるかもしれない。

　同様に、Twitterの文化の1つともいえるbot（自動でTwitterに投稿するプログラム）を作成したホビーユーザーが、そのbotをOAuth認証に対応させるかどうかは分からない。中には、そのまま放置されて活動を停止するbotも出てくるだろう。

　また、丹羽氏がとりわけ悩ましいと感じているのが、日本の携帯電話だ。同氏は次のように語る。

　「Web標準に準拠していない日本の携帯電話の特殊性は悩ましい。例えば、（日本の携帯電話で今なお多い）Cookie非対応のブラウザだとセッションが維持できないのでOAuth認証がそのままでは使えない。さらにいえば、認証画面をレンダリングすることすらままならないので、実質的には使えない。もちろんこの問題は認識していて、どこかのタイミングで対応したいが、標準からかけ離れているので悩ましいところだ。当面の間、携帯電話のアプリケーションはxAuthを利用してほしい」（丹羽氏）

企業のPRやマーケティングでTwitterを使っている場合は注意を

　さらに丹羽氏は、今回のBASIC認証廃止により、企業アカウントの対応が盲点になるかもしれないと警鐘を鳴らす。ご存じの通り、Twitterが市民権を得るにつれ、そこをマーケティングに利用する企業も増えた。Twitterアカウントをキャンペーン目的で作成し、利用している企業は枚挙にいとまがない。

　このうち、投稿やフォローを自動的に行うようなタイプのものは、BASIC認証を用いている可能性が高い。7月前後にTwitter上でキャンペーンを予定しているビジネスユーザー、あるいは、現在Twitter上でキャンペーンを展開中で、7月以降もそれが継続するようなケースでは認証方式を再確認するべきだろう。7月以降にユーザーから指摘されてOAuth認証対応を図るという愚は避けたいところだ。

　まとめると、Twitter APIのBASIC認証は6月30日で終了する。Twitterとしては、WebアプリケーションではOAuth認証を、OAuthの利用が困難な携帯電話を含むデスクトップアプリケーションではxAuth認証を利用してもらいたい意向だ。先日発表された「ChirpUserStreams」のように、Twitterのリアルタイム性をさらに享受できるStreaming APIの提供、さらには任意のサイトにTwitter機能を埋め込める「@anywhere」など、Twitterを活用するシーンはますます増えていくことだろう。エンドユーザー、デベロッパー、企業利用もいずれもBASIC認証との決別に備えたい。

「@twitterapi's countdown to Basic Auth removal」のサイトでは6月30日に向けたカウントダウンが進行中だ

企業向け情報を集約した「ITmedia エンタープライズ」も併せてチェック