で、別にそんなに大したことをやるつもりもないんですが、アプリ登録してAPIを使う以上、一応OAuthとかその辺理解しておくべきかな、と思い、まぁ内容的には知ってる人からすれば周回遅れ的なものなんでしょうけど個人的な整理として。
先に要点を書くと、
この記事を書いてる現時点（2014/04/17）で、
・Tumblr APIのアプリ承認方法はOAuth1.0aとxAuthが提供されている。
・TumblrのOAuthではPINコードの入力による承認は提供されていない。
・OAuthのcallback URLの固定は出来ない。
・「xAuth」。XAuthでもxauthでもXAUTHでもない。それぞれ全部別物。（なんでこんなことなってんの…？）
・クライアント型アプリの場合いずれの手段でもconsumer secretは秘匿できない。
Webアプリはまぁいいよね
んで、ユーザースクリプトとかの個人利用的なものを除けば、この手の承認を第三者に要求するのはサーバサイドで動作する「Webアプリ」と、デスクトップアプリケーションやモバイルアプリケーションなどの「クライアント型アプリ」に大別されるわけですが、まぁWebアプリに関してはクライアントサイドJSで無理矢理やろうとか試みない限り（クライアント型アプリは
問題はconsumer key & consumer secret（2.0ならapp_id & app_secret）を埋め込んでユーザーの手元に置く形になるクライアント型アプリ。クライアント型アプリのOAuthについてはTwitterの騒動とかもあったりして、
「秘密の情報もない」し「callback URLを強制」することもできていない。偽のクライアントを作ることが出来て、callback先は自由に設定できる。何でこれで安全に実装できると思っているんだ!! ギルティ!!
なことは理解していたんですがその辺Tumblrはどうなってるんだろう、と。
callback URLが登録時のURLに固定になってたりするんじゃなかろうか、とか勝手に思ってたんですが、試してみると全然そんなことはなくてリクエスト時にフツーに任意のURL指定できました。あれ？
じゃあURLにcallbackする形でなくPINコードの入力方式で、と思いきやTumblrではこちらはそもそも提供されてないっぽい。んぁ。
ってことで、どうもクライアント型アプリではOAuthは使うべきでないっぽいのかなぁ、と思いxAuthの方を調べてみることに。
じゃあxAuthは？
で、じゃあxAuthはどうなんだろう、と。Tumblrのアプリ登録のページを見ると
Web apps should use the standard OAuth flow, reserving xAuth for apps in which the web authorization process is impractical or impossible, such as native desktop or mobile apps.とあります。
「WebアプリはOauth使ってね、xAuthはWebページでの承認が現実的でないor不可能な デスクトップ、モバイルアプリのためのもんだよ」ってな感じでxAuthの使用には申請が必要になっています。
つーかそもそもxAuthってなんぞや、と。
「xAuthってなにそれXO醤ソースみたいおいしそう」ぐらいの知識しかなかったわけですが、ざっと調べた感じでは、「根本的にはxAuthもまたOAuth」である上で、「OAuthと違いユーザーIDとパスワードをユーザーから直接（一時的に）受け取ることでcallback URLやらPINコード入力やらを介さずにtokenを受け取る。」というものである模様。
OAuthと比較して、メリットとしてはサーバ側（callback URL）を用意しなくて良い。なのでcallbackの過程でごにょごにょを考えなくて良い。
デメリットは、OAuthのメリットであるユーザーからアプリ（クライアント）が直接IDとパスワードを受け取らなくていいというのがなくなるぞ、と。
ふむ。
…で、結局consumer key & consumer secretは埋め込むと。
ということは…？
・Tumblr APIを利用したクライアント型アプリを開発&配布する場合、consumer key & consumer secretを抜かれて偽クライアントを作られるリスクは常に存在する。
・自分のアプリのconsumer key & consumer secretを流用した悪意あるアプリをエンドユーザーが承認しないことを信じるしかない。最後のラインは個々のユーザー任せ。
ということ。
なの…？
まぁでもユーザー側で言えば、それがconsumer key & consumer secretを流用した偽クライアントだろうが純正の（?）悪意あるクライアントだろうが、承認すべきで無いことに違いないわけで、結局個々のユーザーがアプリの承認or拒否という判断に責任をもつしかない。Twitterの場合は他の要素も複合的に絡んでたわけで。
だからまぁ一応はこれでいいということになる…のかなぁ。
…そうなの？
…本当に？
まとめ
ということで「まとめ」とか書いてますが正直なんかまだもやもやしてます。とりあえずはっきりしているのは、その辺もやもやしてるうちは僕はTumblr APIを使ってクライアント型アプリを作るべきではない、ということでしょうか。（もともとないけど。）
結局のところ「OAuthは元々Webアプリ（Webサービス）間の連携のためのものであってクライアント型アプリの承認を想定したものではない。」ということは頭に置いておく必要がある、ということでしょうかね。
というか「OAuthはそもそも『承認』の仕組みであって『認証』の仕組みではない。」という言われてみれば至極真っ当な指摘も各所で散見しました。
うーんなんかうまいことなんないんですかねぇこの辺。（丸投げ）
※1
※2 2014/4/19追記：他の方の書いたユーザースクリプトみてたらやってるっぽい記述があったので実際のところどうなのかはよくわからない
0 コメント