Hatena::ブログ(Diary)

r-weblife RSSフィード Twitter

2012/06/19

OAuthなプラットフォームの中の人が椅子を投げたくなるアプリの実装

こんばんは、ritouです.

世の中, OAuthの仕様に沿って提供されているAPIだらけです.

モバイル端末で動作するアプリでも, そんなAPIを利用するものだらけです.

OAuthなユーザーフロー

アプリのOAuth実装となるとそれはそれはこまけぇことでいろいろあります.

とりあえず, OAuthなプラットフォームを提供する側は以下のようなユーザーの動きを望んでいます.

  1. mixiと連携するボタンを押す
  2. 外部のブラウザが立ち上がる
  3. 未ログインの場合はログイン画面が表示されるが, 頑張ってHTTPS+ドメイン名とかを確認してログイン
  4. アプリによるリソースアクセスに対して同意
  5. アプリに戻って連携完了

やや複雑なものに思えるかもしれませんが, OAuthなプラットフォームを提供している中の人たちからすると,

アプリがID(Email)/PWなどを直接扱わないことで意図的な悪用, 意図しない漏えいからのほげほげなどのリスクを防ぐことができますよ.

と言いたいわけです.

(6/21 追記 : TwitterのxAuthのようにOAuth 2.0でもユーザーのクレデンシャルを扱うフローも定義されていますが、現状のモバイルアプリのようにブラウザが立ち上がる環境では利用を避けるべきという認識でいます。よって、今回の記事の中ではClientがクレデンシャルを扱わない実装を"OAuthの実装"とさせていただきます。)

この実装は投げる

(6/21 追記 : mixvTweetの開発者の方からコメントがあり、スクレイピングとAPIアクセスを併用しているとのことでした。

スクレイピングを利用するアプリに関してはさらにいろいろな論点があると思っているため、本エントリではOAuthのAPIのみ利用しているアプリを対象にしています。

確認不足で不正確な情報を流してしまい、申し訳ございませんでした。)

あるAndroidアプリの画面を見てみます.

mixvTweetというアプリです.

これはマルチポストができるアプリですかね, Twitter, mixiのボイス, Facebookに投稿できます.

こちらのアプリは別件で使ってみることにしたのですが, 設定画面を見て驚きました.

各サービスとの連携のための画面はこちらです.

f:id:ritou:20120619192106p:image

アプリ側がEmail/PWの入力を求めています.

アプリが生のEmail/PWを扱ってますね。スクレイピングの類かな?

せっかくクレデンシャルを扱わないOAuthなプラットフォームを提供しているのに残念です.

これはひどい.

まぁ、切り込まなければならないということで、覚悟してEmailとPWを入力しました.

途中でいかがわしいことを考えてしまいPWを打ち間違えたところ, "認証NG"となりました.

やはり, なんらかの方法でEmail/PWの正当性をmixiに確認しています.

ログイン画面をあーしてこうして....

とりあえず正しいPWを入力すると, 次の画面がこうなりました.

f:id:ritou:20120619192107p:image

これはOAuthのリソースアクセスの同意画面です.

このアプリはフルでスクレイピングしまくってほげほげではなく, ご丁寧に入力したEmail/PWでログインさせてくれるようです.

もしかしたらログイン画面が出て自分でログインするよりスムーズな処理になるのかもしれません.

親切?でもやっぱりそれじゃOAuthの意味ない.

同意画面を出されたところでWebView?なのでURLやドメインも確認できません.

そもそも勝手にクレデンシャルの検証するんじゃねーよと.

ということで、このアプリの開発者の方にはぜひ"Facebook連携"と同じ実装にしていただくよう願うばかりであります.

自分のアカウントのパスワードをアプリに渡すことをよしとしないのであれば, このアプリは使わない方が良いと思います.

もう既に使っている方は連携解除したあとにPW変更した方が良いかもしれません.

アプリが受け取ったPWをどこかに保存していたりしているかもしれないですからね.

(追記)例え悪いことをしていないとしても、PWを受け取った時点でできる状態になっているので疑われるリスクがありますよということです。

他に, TkMixiViewerというアプリがありますが, こちらもEmail/PWをアプリでもらい同意画面が出てきます.

しかも、同意画面でキャンセルしても情報がひっぱられるという不思議な現象が起きているのでスクレイピングが行われているんじゃないかとふんで調査中です.

絶対に守っていただきたいこと

公式アプリ、webサイト以外にEmail/PWを入力したり渡すかどうかはユーザーが決めることですが、悪用されるリスクまで考えたらやはり今回のようなアプリは良くないですね。(twitterの指摘によりあっさり方向転換)

OAuthなプラットフォームを提供している人たちからしたら椅子を投げたくなるような実装はまだまだたくさんありそうです.

アプリ開発者の皆様、OAuthのプラットフォームにて提供されているAPIを利用する際は, ユーザーのID(Email)/PWを直接扱わないでください!

以上, よろしくお願いいたします.

kzyskzys 2012/06/20 09:58 Twitter のパスワードをとる理由は謎ですが (xAuth?)、こと mixi に関していうと、スクレイピングでとれる情報と documented な API でとれる情報との間におおきな開きがあるので、そこにふれずに数少ないクライアントアプリケーションを責めるのは酷なように思いました。

ritouritou 2012/06/20 14:50 > kzysさん
コメントありがとうございます。

> スクレイピングでとれる情報と documented な API でとれる情報との間におおきな開きがあるので、そこにふれずに数少ないクライアントアプリケーションを責めるのは酷なように思いました。

今回一番言いたかったのは、ユーザークレデンシャルを扱わなくて良い方法が提供されている+それしか利用しない場合はPW扱っちゃだめっすよという点です。
最後のお願いのところで"OAuthのプラットフォームにて提供されているAPIを利用する際は〜"と書いたのもそのためです。
mixvTweetはOAuthのAPIのみを利用しているので、最初にユーザークレデンシャルを扱うとこだけ直してくれたらいいのになと思っています。

スクレイピングを利用するアプリに関してはちょっと話が変わってきますね。
今回の内容ではスクレイピング=極悪のように言ってるように見えたかもしれませんが、単純に"ダメ、絶対"とは言うつもりはありません。
ご指摘の通り、APIで提供されてない機能についてはスクレイピングによりできることが広がる場合もありますし、ユーザーがクレデンシャルを預けることによるリスクを理解して(できて)それでも利用するなら問題ないと思います。
こちらはまた、別の機会に書きたいと思います。

sakurai_youheisakurai_youhei 2012/06/20 23:05 OAuthでアプリがすべきでない事はパスワードを扱わないことではなく、パスワードを永続的に保存する事では?パスワードの代わりにトークンをアプリの中で永続化しましょうと。少なくとも数年前のDropboxはそういうAPIリファレンスだった、今は知らないけど。

sakurai_youheisakurai_youhei 2012/06/20 23:38 コメントしといてすいません、理論が変です。扱わない→扱う、パスワード→クレデンシャルと訂正したく。

ユウジユウジ 2012/06/21 00:32 ご指摘いただいたAndroidアプリmixvTweetの作者です。
アプリにてID・パスワードを保持する実装となっていることについては、私も問題がある旨は認識しております。
mixvTweetではmixiボイスの投稿などはAPIで、mixiボイスの閲覧はスクレイピングで行っています。
上記コメントにもありますが、mixiではAPIで取得できるデータとページ表示されるデータに差異があるため、しかたなく、このような実装としている旨、ご認識いただきたいです。
なお、mixiボイスデータもAPIで取得できることは認識しております。
しかし、設定によってはAPIに反映されない場合があり、mixi利用ユーザ層のリテラシを鑑みて、Web版と同等の結果を閲覧できるよう、スクレイピングを選択しています。
なお、当件については考え方の違いは埋められないと思いますので、作者として議論を長引かせるつもりはございません。
記事を閲覧した方にアプリの事情を知っていただき、自己責任でアプリ利用していただければ幸いです。

ritouritou 2012/06/21 00:43 > sakurai_youheiさん
ご指摘ありがとうございます。

たしかに、アプリが直接クレデンシャルを扱うフローもOAuth 2.0には含まれています。
Twitterが提供しているxAuthもOAuth 1.0aの拡張的なものです。

これらはクレデンシャルを永続的に保持するBasic認証などに比べるとリスクを抑えることができますし、フィーチャーフォンなど制限のあるクライアントでは使わざるを得ないこともあるでしょう。

ただし、ブラウザを扱える現状のモバイルアプリではクレデンシャルを扱わない今回示したようなフローを使用すべきです。
"The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible."
http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-10.7
OAuth 2.0に準拠しAPIを提供しているサービスもこのフローの実装を避けているところが多いです。

あまり細かい記述をしなかったため文章的には正確ではありませんが、
"クレデンシャルを扱わないフローが提供されている場合は使わないでください"とした方が良かったですね。追記しておきます。

ritouritou 2012/06/21 02:01 > ユウジさん
コメントありがとうございます。

スクレイピングとAPIの併用だったのですね。
自分で試してみたのは連係解除してPOSTに失敗するとこまでだったため、APIのみ利用しているものと勘違いをしておりました。
確認不足で不正確な情報を流してしまい、大変申し訳ございません。
本エントリでは"OAuthのAPIのみ利用するのになんでアプリが扱ってるの"ですので、本アプリは対象外だったとして本文を修正いたしました。

> mixiではAPIで取得できるデータとページ表示されるデータに差異がある
> 設定によってはAPIに反映されない場合があり、mixi利用ユーザ層のリテラシを鑑みて、Web版と同等の結果を閲覧できるよう、スクレイピングを選択しています。

なるほど。差異や設定の詳細が気になりますが私の方でも確認してみたいと思います。

suzusuzu 2012/06/22 15:24 >ユウジさん

はじめまして。通りすがりに失礼します。

>mixiではAPIで取得できるデータとページ表示されるデータに差異があるため、
>しかし、設定によってはAPIに反映されない場合があり、

この部分をもう少し具体的に教えて頂けませんでしょうか?
「外部サービスのプライバシー設定」で友人Aが「外部サービスに自身の情報を連携しない」を選んでいる場合、
APIで取得した私の「友人のつぶやき一覧」に友人Aの情報が含まれない為・・・混乱を避けるためにスクレイピングを選択しているということでしょうか?

よろしくお願い致します。

teracc2teracc2 2012/06/24 22:15 mixvTweetとかスクレイピングの話はちょっとおいておいて、
OAuth連携をWebViewでやることについてritouさんのご意見をお聞きしたく、コメント書かせてもらいます。

> アプリがID(Email)/PWなどを直接扱わないことで意図的な悪用,
> 意図しない漏えいからのほげほげなどのリスクを防ぐことができますよ.

アプリが悪意を持っていることを想定してみます。
その場合、

> 2.外部のブラウザが立ち上がる

のようにみせかけて、アプリはブラウザのように振舞う偽の画面を起動できますよね。

その画面が本物のブラウザか偽物かをユーザが識別するのは、(突き詰めて考えると)今のAndroidのセキュリティモデルでは難しいように思うのです。

> 3.未ログインの場合はログイン画面が表示されるが, 頑張ってHTTPS+ドメイン名とかを確認してログイン

なのでアプリの悪意を想定してしまうと、ユーザの3の頑張りは報われないような気がしています。

というところで私は思考停止してしまっているのですが、
そのあたりについて何か考えてらっしゃることがあれば是非ご教示いただきたく・・・。

matakematake 2012/06/25 00:06 それは一般ユーザーには難しいでしょうね。

そういうアプリを通報するのが僕らの役目であり、
そういうアプリをBanするのがmixiの役目であり、
そういうアプリをマーケットから排除するのがGoogleの役目ではないでしょうか。

そして、スクレイピングしときながらOAuthの同意画面見せるイミフなアプリを通報しようとすると、お前Android持ってないから出直してこいとかいうGoogle Playは...sigh..

ritouritou 2012/06/25 02:48 > teracc2さん

突き詰めて考えるとAndroidに関わらずPCのWebブラウザでもOAuthのフローにおけるフィッシングのリスクはありますし、外部ブラウザを正しく利用してもアプリへの戻りの部分など、リスクを考慮すべき点はたくさんあることも認識しています。

悪意がある開発者を想定して同じレベルにしかならないのであれば、悪意のない開発者の場合に少しでも安全な方に倒せそうな外部のブラウザの方が良いのではないかと思っています。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/ritou/20120619/1340101421