OAuth
2012年08月17日
以下の記事を見つつ、ポイントをまとめていくとともに、私の考えを述べていく。
●原文：Changes coming in Version 1.1 of the Twitter API | Twitter Developers（基本的にはこれを参照します）
●日本語での要約：Twitterブログ: Twitter API v1.1でのAPI利用ルールの変更について
●参考記事：Twitter、開発者向けガイドラインとAPI変更について説明 ユーザー数制限など厳しい内容 - ITmedia ニュース
【Authentication required】（認証が必須になります）
現行では、statuses/user_timeline（一人のユーザを指定して発言を取得）のような「Twitterにログインしていなくても見られる情報」に関するAPIは、認証情報を送らなくてもアクセスすることが可能であった。しかし仕様変更後は、どのAPIでも認証情報を送る必要が生じる。現在、私がHHiro.net内で動かしているTwitter向けツールでは、TwiPieces以外すべて改修が必要になる。あと個人的に動かしているボットとかツールとかも。
でこの改修なのだが正直面倒である。OAuth対応は本当に面倒くさい。方針としては、私自作のTwitterボットライブラリ「twbot2.rb」からOAuth関連部分だけ切り出して対応しようと考えている。
【Per-endpoint rate limiting】（API呼び出し対象ごとの規制）
簡単に言えば、statuses/user_timeline と statuses/home_timeline はそれぞれ別枠でAPI呼び出し回数の規制をしますよ、という話。ユーザごとにAPIを使うサービスならあまり影響はないものの、ふぁぼったーのような「多数のユーザから取得する」サービスがつらい、という話も。参考：F's Garage @fshin2000 ：Twitter api ver1.1、痛いところ、痛くないところ
ちなみにこれは、あくまでタイムライン取得系APIの規制の話で、発言数規制やふぁぼ規制は（現行のスキームが維持されるなら）別枠で計算される。
【Changes to the Developer Rules of the Road】（開発者が従うべきルール）
【Display Guidelines will be Display Requirements】（「表示ガイドライン」は「表示の必須要件」に）
Twitterでは、ツイートを表示する場合のガイドラインとしてDisplay Guidelines（英語）を用意していて、「アイコンは必ず表示する」「ユーザの名前とユーザのアカウント名はアイコンの隣に表示する」「ツイートを選択したりしたときは、返信・お気に入り・リツイートが必ず出来るようにする」などのガイドラインが存在している。これは現状では推奨される表示方法という位置づけであったが、これが必須になる。ここで大きな問題があって、例えば「動作を軽くしたいからアイコンを読み込まない、というのは認められないのか」とか、「表示する情報量を増やしたいから、オプションとしてユーザの名前は表示しないようにする、というのは認められないのか」といったことが挙げられる。ちなみにDisplay Guidelinesで個人的に気に入らないのは、発言時刻の表示について「24時間以内の発言の場合は"●●時間前"などの表示を、それ以前のものは日にちのみを表示」と決められていること。個人的にはどんな場合でも、日時と時刻で見えていて欲しいので。
ちなみに、「この要件を守らないアプリケーションの許可を取り消す権利が我々にはある」（原語：If your application displays Tweets to users, and it doesn't adhere to our Display Requirements, we reserve the right to revoke your application key.）とあるので、サードパーティのクライアントもこのガイドラインを強制される、すなわち「自分の好きなUIでTwitterを楽しむ」ことが出来なくなってしまうんじゃないかという懸念がある。
【Requiring pre-installed client applications to be certified by Twitter】（Twitterを利用するプリインアプリは許可を受ける必要あり）
パソコンやスマフォなどのプリインアプリが対象。理由としては「プリインアプリが更新されるには時間がかかるから」とのこと。【Requiring developers to work with us directly if you need a large amount of user tokens】（大量のトークンが必要な場合はTwitterと直接協業する必要あり）
ここでトークンというのは、OAuth認証における、ユーザとアプリの組に対して与えられる認証用文字列のことで、つまりは「大量のユーザを対象とする場合は」という話である。1つのアプリが、Twitterに許可を得ずに受け入れられるアカウントの数は10万に制限される。ただしすでに10万を超えているアプリなら、その2倍までは拡大が認められる。
【API v1.1 migration period】（API v1.1への移行期間）
6か月待ちますよ、とのこと。【Today's Twitter ecosystem】（現在のTwitter界の体系）
結論から言うと、Twitter社としては「Twitterクライアントはあまり作って欲しくない」とのこと。現在のTwitter APIの使われ方を「ビジネス向けか一般利用者向けか」（Business/Consumer）「Twitterを利用するのか分析するのか」（Engagement/Analytics）という軸で分け、そのうち右上の項目 "Consumer+Engagement" についてはAPIをあまり使って欲しくない、とのことであった。（原語：limit certain use cases that occupy the upper-right quadrant）
で、このConsumer+Engagementに含まれるものとして、「traditional Twitter clients」（これまでのTwitterクライアント）や、「Syndication」（発言を見せたり広めるためのサービス、という意味と思われる。Favstarなど）が入っている。
確かに現在だと、ブラウザのインターフェイスが多機能化してブラウザだけでもかなり使いやすくなったし、モバイルアプリも公式で揃っているというのはあるけど、歴史的経緯からすれば「色々な人が知恵を出して＆技術を身につけて作った」から多数のクライアントアプリがあるわけで、そういう開発者にとってはもちろん面白くないし、「様々なクライアントがあるから自分にあったものを見つけられて、それによってTwitterを楽しめている」人にとっても面白くないと思う。
ただTwitter社の意向としては、どうも「どんなユーザエクスペリエンスを提供するかは、Twitter社がコントロールしたい」ようなのである。上記の表示ガイドライン然り。
（参考記事：Twitterの将来を握っているとされる"Twitter Cards"とは：InstagramへのAPIも閉鎖したTwitterの将来像 - the Public Returns - 続・広報の視点）
【Looking ahead】（前を見て）
Twitter Cardsの話。上記のリンクにも書いてあるのだが、ユーザ側で「Twitterで見ると画像などが表示される」ようなサービスを作るための仕様である。ちなみにこの節の最初の一文を訳すると、「API v1.1以降では、Twitterにあるコンテンツを使って何かするだけではなく、Twitter Cardsへの対応も考えて欲しい」という内容。言い換えれば、Twitterから情報をもらうだけじゃなくて、Twitterへ情報を渡すこともして欲しい、とのことだろうか。
【結論】
結局のところ、「今までは外部サービスに支えられてきたけど、今後は徐々に、Twitterが主要な部分を握った上でAPIを使ってもらいますよ」という方向転換をしたというのが見て取れる。上記のthe Public Returnsの記事で言われている通りなのだが。でこの構図、どこかで見たことあるなーと思ったのだが、考えてみたら「プラットフォームの主要な部分はユーザに使わせず、それによってユーザエクスペリエンスを向上させるiPhone」vs「ユーザに自由に使わせることで、使い方自体をどんどん広げてもらうAndroid」がそれだった。
なので、この舵の切り方がうまく行けば、Twitterという世界に統一感が生まれてユーザにとっても分かりやすくなるとは思う（それでも私は快く思わないけど）。ただ一方で、現行の開発者の離反を招くのは確かなので、そこでコケないのかという懸念も感じるのである。
【余談】
交流ツール、情報収集ツールとしてTwitterを使うのはしばらくやめそうにないけど、自分がTwitterに対して開発者魂が疼かなくなっていきそうなのは確かなので、自分は何か代わるサービスを探した方がいいかもしれない。2011年08月16日
【はじめに】
2011年8月1日から、foursquareの旧APIの利用が停止され、新APIのみが利用可能となった。ところでこのfoursquareの新APIでは、OAuth2という認証方法が採用されている。
参考：OAuth 2.0でWebサービスの利用方法はどう変わるか（1/3）- ＠IT
そもそもOAuthというのは、foursquareやTwitterなどのWebサービスが、関連サービスに認証情報を預けるための機構である。OAuthがなければ、Twitter関連サービス（例えば、活動をTwitterに通知する機能を持つWebサービス）を利用する際、そのサービスにTwitterのユーザ名とパスワードを教える必要があり、セキュリティ上の問題となっていた。OAuthを用いると、そのサービスにはパスワードの代わりに別の認証用文字列が渡り、それを用いることでTwitterの機能を利用することが出来るのである。
参考：APIアクセス権を委譲するプロトコル、OAuthを知る − ＠IT
さて従来型のOAuthは、通信の手順が煩雑であり、プログラム言語や環境に応じたライブラリを経由して利用するのが普通であった。一方でOAuth2はこの手順が大幅に簡略化され、通信回数、引き渡すパラメータ数ともに非常に少なくなっている。
参考：Authentication - API Documentation | foursquare Developers
WindowsMobile向けfoursquareクライアント「Quick4sq」の新API対応版を作るにあたり、OAuth2をC#で実装したので、そのサンプルコードを配布させていただく。
【ソースコード】
http://maraigue.hhiro.net/quick4sq/oauth2sample.zip
念のためMIT Licenseとしておきますが、使っていただくにあたり「転用時に出典元を示す」のみでも十分です。なお同梱のLitJSON（後述）については、パブリックドメインとなっております。
【必要なもの】
- （当然ですが）foursquareのアカウント
- Webサーバ（レンタルサーバの適当な場所に空のHTMLを置いておき、そのURLを控えておく。なければブログ等のURLでもOKだが、その場合なるべく軽いページがよい）
- Visual Studio 2008 (2010で動くかは検証していません。もしソリューションファイルを直接開けないようでしたら、ソースファイルを直接プロジェクトに追加して下さい。なお配布のファイルは.NET framework 2.0を指定してあります。)
【1：アプリケーションを登録する】
(1) https://ja.foursquare.com/oauth/にアクセスする。
(2) 「REGISTER A NEW CONSUMER」に進むと、以下のような画面が現れる。
「APPLICATION NAME」（アプリ名）、「APPLICATION WEB SITE」（アプリのウェブサイト）は適当に指定する。「CALLBACK URL」が重要で、ここに先程の空のHTMLにアクセスするURLを指定する。例えばQuick4sqでは「http://maraigue.hhiro.net/dummy/」を指定している。
いずれも、後で変更することは可能である。
(3) 登録が完了すると、「CALLBACK URL」「CLIENT ID」「CLIENT SECRET」の3つの情報が表示される。「CALLBACK URL」は先程登録した通りである。「CLIENT ID」「CLIENT SECRET」の2つが、そのアプリに割り当てられたランダムな文字列である。今回はこのうち「CLIENT ID」が必要となる。
【2：foursquareにアクセスする】
配布したコードの「Form1.cs」中に、「CALLBACK URL」と「CLIENT ID」を記入する場所があるので、そこに今表示されたものを記入する。あとはそのコードを実行すれば、OAuth2による認証・トークン取得と、それを用いたfoursquare APIへのアクセス（今回は、認証されたユーザがどんな名前でfoursquareに登録しているかを取得するのみ）を試すことができる。
なお、foursquare APIは返り値をJSON形式で返すのだが、JSONを取り扱うライブラリとして今回はLitJSONを利用させていただいた。これは新規にJSONのパラメータが増えてもソースコードの修正が不要なため、外部サービスのAPIを取り扱う上で都合がよいこと、またソースコードの微小な修正で.NET Compact Framework（WindowsMobile等向け）に対応できるためである。
【おわりに】
OAuthはプログラマ泣かせと言えるほど複雑な仕様だったのですが、OAuth2はユーザの使い勝手を保ちつつ、プログラマへの優しさもかなり向上しました。もっと流行ってほしいです。
2010年05月05日
●OAuth非対応版のtwbot.rbからの移行を容易にする
●ブラウザが使えない環境でも認証が出来る
という利点からxAuthを利用したかったのだが、非常に残念。
以下、その時のやり取りの内容。（原文は英語。大雑把な意訳です）
Twitter APIの管理者（以下「管」）：「xAuthの利用許可を1週間だけ出しました」
私：「ライブラリが完成したら継続的に利用できる、ということなのでしょうか？」
管：「いいえ、それは出来ません」
私：「それだと、ライブラリ利用者に不便を強いることになるので、出来ればxAuthを継続的に使いたいのですが…」
管：「xAuthの仕組みは、ライブラリに対して適用するには適していないので、現状ライブラリに対してはxAuthを継続的には使わせないことにしています」
私：「ライブラリだとどこが都合が悪いのですかね？デスクトップで利用するTwitterクライアントと比べて違わないと思うのですが」
管：「コンシューマトークン(*1)がソースコード中に生で書かれますよね？なので他のユーザが容易に、そこだけ置き換えて利用出来る（＝Twitter投稿時に表示されるアプリケーション名を勝手に置き換えて利用出来る）のが問題なのです」
私：「とりあえずそちらの運用については分かりましたが、それって、デスクトップで利用するTwitterクライアントであろうとも、それがオープンソースで開発されてたら同じ問題抱えてますよね？今はxAuth使わないことにしますが、とりあえず、そちらの運用には納得行かない、ということは明言しておきます」
てことで、かなり不満を抱えつつも、twbot.rbのOAuth版はxAuthなしで使えるような形でリリースします(*2)。
----
(*1)アプリケーション単位に割り当てられるOAuthトークン
(*2)xAuthを使う部分のコードは残したままリリースします。ただしそれを用いてアクセスしても、xAuth利用の許可が出ていないため「401 Unauthorized」のエラーになります。
2010年02月15日
タイトル長めですが、大事なことなので全部書きました。
コードはこちら：
- メインのライブラリ/タイムラインを取得するサンプル
- gist: 304123 - GitHub（最終更新：2010.02.15 11:26）
- 発言を投稿するサンプル（上記ライブラリと組み合わせてご利用下さい）
- gist: 306853 - GitHub（最終更新：2010.02.18 3:09）
概要
Twitterでは、OAuthという認証のシステムが利用できる。
従来は、（ユーザ認証を伴う）TwitterのAPIを利用する際、APIの呼び出しのたびにユーザ名・パスワードを送信する必要があった。一方OAuthでは「トークン」と呼ばれる、ランダムに生成された文字列を、APIへのアクセス権限を証明するものとして発行する。実際にAPIを利用する際には、このトークンを用いてアクセスすれば、ユーザ名やパスワードを送信する必要はない。（詳しくはAPIアクセス権を委譲するプロトコル、OAuthを知る − ＠ITを参照）
なお、「あるユーザAの出来る行為」に対応するトークンを発行するためには、(1)ユーザAがTwitterにログインした状態でトークン発行ページにアクセスするか、(2)ユーザAのユーザ名およびパスワードを送信してトークンを直接取得する(xAuth)必要がある。
トークンを介する利点として、Twitterと連携するウェブサービス（例えば、アップロードした写真をTwitterに通知する）が、Twitterユーザのパスワードを直接記録せずにTwitterの機能を利用できるということが挙げられる（(1)の方法を使えば、ウェブサービス側にはトークンしか通知されないため）。これはセキュリティ上も、ユーザの心理という面でも便利である。
経緯
上記(1)の方法でのトークン取得が、Twitterと連携するウェブサービスに適した方法であるのに対し、(2)の方法は、各個人のコンピュータにインストールされるTwitterクライアントなどに適しているといえる。これらのクライアントは、ブラウザと無関係に動くほうが当然便利であるし、またユーザがパスワードをクライアントに伝えずに利用することはそもそも不可能だからである。
(1)の利用法はすでに多く用いられている一方、(2)の利用法はあまり広まってはいないのが現状である（後述）。これは(2)の方式が後で追加された仕様であること、また従来の「APIの呼び出しのたびにユーザ名・パスワードを送信する」方法（具体的には、Basic認証）で事足りていたというのが大きいと思われる。
しかしつい先日、TwitterがBasic認証でのAPI利用を6月ごろに終了するというアナウンスを出した。そのため、今後はBasic認証を用いていたサービス・アプリケーションは、OAuthを用いるものに移行する必要が生じた。
さて、私はtwbot.rbという、RubyでTwitterボットの制作を補助するライブラリを作っている。これはxAuth、つまり(2)の方法でのトークン取得が適しているケースといえる。しかしWeb検索を利用しても、RubyにてxAuthでトークン取得を行うためのコードが見つからなかった。それを書いたのがこのコードである。
これまでのコードと解決法
これまでにも、RubyにてOAuthを利用するコードはいくつか公開されていたものの、いずれも(1)の方法、すなわちブラウザを介してトークンを取得するものであった。
Twitterでこのことについて投稿したところ、@rokudenashi氏から「xAuthでのトークン発行はすでに実現できている」との情報をいただき、そのPythonコードを拝見させて頂いた。そこで、これをRubyに移植することにした。
さらに調べたところ、xAuthはHTTPヘッダに追加の情報を加えることで行うことが分かった（参考：OAuthでデスクトップアプリがブラウザを経由させたくないときのxAuth - Codin’ In The Free World）。これを踏まえ、RubyのOAuthライブラリのリファレンスや、xAuthを利用しているコードの一部とにらめっこしながら、前述のコードを書き上げるに至った。
コードの解説
大した内容ではありませんが、念のため解説。
最初のconsumer = OAuth::Consumer.new …の部分は、他のサンプルなどでも見られるコードである。ただし、アクセス先を「https://」と「api.twitter.com」にしないとならない模様（「http://」では403エラーになった）。
次のconsumer.get_access_token …の部分で、いきなりアクセストークンを取得する（(2)の方式でなく(1)の方式を用いる場合は、その前に「リクエストトークン」という別のトークンを取得する必要がある）。この際、HTTPヘッダにユーザ名やパスワードを書いておく必要があるため、第3引数にユーザ名・パスワードおよび、「:x_auth_mode => "client_auth"」（xAuthを利用している、という情報）を加えてある。
追記：OAuthのアプリケーション登録方法
（2010.02.18 3:09追記）
本コードは、利用される皆様がそれぞれOAuthのアプリケーションを登録する、という想定のもとで書かれています。お手数ですが、OAuthのアプリケーション登録を行い（参考：TwitterのbotをOAuthに対応させる - しばそんノート→「OAuthクライアントを登録する」）、そのConsumer key/secretを用いてお試し下さい。
（2010.04.15 23:14追記）
遅ればせながら。
Twitter APIにおけるxAuthの正式サービス開始に伴い、メールで申請されたアプリケーション以外はxAuthが利用できなくなりました。（参考：Twitter API Wiki / Twitter REST API Method: oauth access_token for xAuth）
このためxAuthを用いるアプリケーションを作成するには、上記方法でアプリケーションの登録を行ったのち、api@twitter.com に「アプリケーション●●をxAuthでも使えるようにして下さい」という内容のメールをしないとなりません。
おわりに
xAuthの利用方法について貴重な情報を下さった@rokudenashi氏、IRCで議論して下さった@niku_name氏・@onodes氏、更にインターネット上の各情報に感謝の意を表します。
このコードが、皆様のRubyでのxAuth利用の助けになれば幸いです。
