SlideShare a Scribd company logo
OAuthで気持ちのいいアクセス制御をKousukeEbihara <ebihara@tejimaya.com>
Twitter 中毒のみなさんこんにちは
Twitter にはサードパーティの色んなクライアントやサービスがありますね
モバツイッターhttp://movatwitter.jp/
モバツイッター携帯電話から Twitter を利用するためのサイトメール投稿がおこなえたり、連携している画像投稿サイトに投稿した画像を表示できたりなどの多彩な機能を備える
OpenEBIhttp://openebi.com/
OpenEBI位置情報を飛ばして自分のルートを描いていくサイト(拙作)Twitter への同時投稿が可能
ヌイッターhttp://nwitter.com/
ヌイッターヌいたら報告するためのTweetツール(意味がよくわからないけど)
ただし、サービス終了済み
OAuthで気持ちのいいアクセス制御を
悪の親玉?違法性?
「こういう風に」のリンクを辿ってみたhttp://takagi-hiromitsu.jp/diary/20080217.html
OAuthで気持ちのいいアクセス制御を
これは、他サイトであるところの「Twitter」 のID・パスワードの入力を促している。ここに、TwitterのID・パスワードを入力してボタンを押すと、(中略)定型文の書き込み操作を行うという動作をする。しかし、(中略)この動作は、実際にパスワードを入力した人の意図に反する動作となっているようだ。 このようなサイトを設置する行為は、不正アクセス禁止法違反に問われるおそれがあるのではないだろうか。(高木浩光@自宅の日記「nwitter」の違法性について考えてみるより引用)
「nwitter」のサイトには「アカウント名やパスワードなどの情報は一切ヌいてません」と書かれているが、そういう問題ではない。(高木浩光@自宅の日記「nwitter」の違法性について考えてみるより引用)
そう、今まで紹介したサービスは利用者の ID・パスワードを利用することで実現されています
Twitter のID・パスワードをサービスに預けることによるデメリット(利用者)Twitter を勝手に利用されてしまうかもしれない(他のサービスと共通のパスワードを利用した場合)他のサービスを不正に利用されてしまうかもしれないパスワードを生もしくは復号可能な状態にしておかなければならないため、サービスが SQL Injection Attack などへの脆弱性を抱えていた場合、パスワードの漏洩の危険がある
ID・パスワードをサービスに預けることによるデメリット(運営者)極めて重要な個人情報をセキュアでない形で預かることになるパスワードは不正アクセス禁止法の「他人の識別符号」にあたり、これを故意か事故かに関わらず公開することは、第四条の「不正アクセス行為を助長する行為の禁止」に抵触する可能性がある(三十万円以下の罰金)
OAuth登場以前、Twitter の投稿APIを叩くための認証は Basic 認証しかありませんでした
Twitter 投稿用ライブラリなんかも、 Basic 認証を前提に組まれていることが多く、利用者の ID とパスワードを利用したサービスが蔓延しています
mixiのように API を提供していないサービスでも、サードパーティ製サービスがマッシュアップ(笑)したいがために、利用者のID とパスワードを入力させている例が存在します
つまり、サードパーティ製ツールなどの登場が予想されるサービスでは、利用者のプライバシー保護のためにID・パスワードによらないAPI のアクセス制御が求められているのではないでしょうか
そこで颯爽と登場したOAuthTwitter のOpenID実装をおこなっていた Blaine Cook 氏らが、必要としていた API アクセス権委譲に関するオープンなプロトコルが存在していないことに気づき、新たなプロトコルを作成するためのプロジェクトを開始した2007 年 10 月にOAuth Core 1.0 の草案がリリースされたFlickrや Twitter や Google や米 Yahoo など多くのサービスで利用されている
OAuthを使うとどうなるの?まずは使ってみよう!以下の URL に突貫で作ったOAuth対応の Twitter クライアントがあるので、アクセスしてみてください!http://co3k.org/twitter/
OAuthを体感サイトの注意書きをよく読んで、ボタンをクリックする
OAuthを体感Twitter のページに行き、「ubetterっつーアプリが投稿したがってるけどどーすんの?」と聞かれるけど……許可しちゃおうか?
OAuthを体感……の前に、ちゃんと本物の Twitter のサイトかどうか確認しましょう!
OAuthを体感気を取り直してボタンプッシュ
OAuthを体感うべー
見てわかるとおり、OAuthによる認可は、認証に使われるID やパスワードなどの情報を必要としない
認可と認証の違い認証は「その人であるかどうか」のチェック(Authentication)認可は「その行動が許されているかどうか」のチェック(Authorization)
認可とはOAuth (pronounced “Oh-Auth”), summarized as “your valet key for the web,"OAuth(オー・オウスと読みます)は、簡単に言えば、「ウェブにおけるバレットキー」のようなもので、(For immediate release: OAuth Core 1.0 Specification released at Internet Identity Workshopより引用)
バレットキーとはバレットキーとは、例えば、ホテルのバレットパーキング係にキーを渡して自動車を預ける場合に使用されるキーであり、そのキーでは、ドアの解錠やエンジンの始動はできるが、トランクやグローブボックス等の収納コンパートメントを開けることができない。(http://www.j-tokkyo.com/2006/E05B/JP2006-225975.shtmlより引用)
つまりどういうこと?Basic 認証のために ID とパスワードを教えるということは、相手に全権限を与えてしまうことに等しいOAuthでは一部権限のみを許可するトークンを渡す形をとっているTwitter では「読み書き可」「読みのみ可」の二通りの権限が選択できるトークンには有効期限を設けることができる
リダイレクトしまくりでキモイこいつら中でなにやってんの?つ
1. リクエストトークンの取得アタシツール歳?23まぁ今年で24彼氏?まぁ(中略)いいからトモのリソースにアクセスさせてみたいなサイトa. リクエストトークン要求ツールうーん……ちょっと聞いてみるからトモ連れてきてよb. リクエストトークン発行
2. ユーザの承認を得るツール連れてきてやったみたいなc. ユーザをサービスプロバイダに案内するあなた本物のトモさん?本当にこの人にアクセスさせて大丈夫なんだね?サイトd. ユーザを認証し、同意を取るトモさんがいいって言うなら仕方がない。e. ユーザをコンシューマに案内する
3. アクセストークンの取得リクエストトークンはあくまで承認を得るためのものなので、リソースにアクセスするためには別のトークンを用いる。サイトアタシツール(中略)トモのリソースにアクセスさせてみたいなf. ユーザ承認済みのリクエストトークン付きでアクセストークン要求ツール仕方がないなあ。ほら、鍵だよg. リクエストトークンを検証し、アクセストークンを発行
4. リソースへのアクセスサイトh. アクセストークンを使ってリソースを要求アクセスツールi. アクセストークンを検証し、リソースへのアクセスを認める
補足トークン付きリクエストは署名されるHMAC-SHA1 (Twitter はこの方式のみ対応)RSA-SHA1PLAINTEXT (非署名)
なんかすごそうじゃん。じゃあとりあえずOAuth使っておけばよさげだね
残念ながら、OAuthのプロトコルにはSession Fixation 脆弱性が存在します
OAuthに潜む脆弱性2009/04/23(海老原の誕生日!)、ソーシャルエンジニアリングの手法によりセッションを固定化できるという脆弱性がレポートされるID, パスワードや各種トークンやシークレットを盗まれるといった類の脆弱性ではないプロバイダ側で対策が可能である
どういう脆弱性か通常のフローコンシューマの利用開始リクエストトークンを発行アクセストークンを発行し、リソースへアクセスユーザプロバイダにリダイレクトコンシューマにリダイレクト
どういう脆弱性か攻撃フローリクエストトークンを承認ユーザ承認されたリクエストトークンを使い、アクセストークンを発行し、リソースへアクセスユーザにURLを踏ませるコンシューマの利用開始リクエストトークンを発行攻撃者プロバイダにリダイレクト
対策方法承認されてないリクエストトークンでアクセストークンを要求した時点でリクエストトークンを無効にするアクセストークンの要求に回数制限を設ける同じリクエストトークンを使用して複数箇所からアクセスがあったと思われる場合、リクエストトークンを無効にするコールバック URL をパラメータから渡すのではなく、登録制にするTwitter が採っている対策コールバック URL を用いず、コンシューマが使うキーをユーザに手入力させるYammer が採っている対策
対策方法ただし、OAuthプロトコル自体の修正はまだおこなわれていない現在どう対策するべきか協議中近々修正された仕様が公開されるとかどうとかアイディアがあれば是非提案してみてください!
OpenPNE 3.1 とOAuth
OpenPNE3 ではOAuth対応が求められているOpenSocialWebAPIこのWebAPIを利用したサードパーティ製ツールを増やしていきたいですね
OpenPNE3 のOAuth(仮)管理画面から特定のアプリケーションを登録、認可(ほぼすべてのSNS内リソースへのアクセス許可)SNS 全体に関わるアプリケーション:OpenSocialなどコミュニティから特定のアプリケーションを登録、認可(コミュニティに関するSNS内リソースへのアクセス許可)コミュニティに関わるアプリケーション:コミュニティ間のチャットなど個人で特定のアプリケーションを登録、認可(その個人がアクセスできるSNS内リソースへのアクセス許可)
OpenPNE3 は6月中旬リリース(予定)の 3.1.1 でOAuthに対応します
これでOAuthがぐっと身近になりますね!6月中旬が待ち遠しいです!
でもOAuthってなんだか難しそう……
そんなことないです(コンシューマは)
いろいろライブラリが揃っている(コンシューマは)
情報もそれなりに出てきている(コンシューマは)
OAuthのプロトコルはかなりシンプルなので、ライブラリがなくても割となんとかなりそうなくらい敷居は低いはず(コンシューマは)
ということで、Twitter もしくはOpenPNE3 向けにOAuthアプリ作ってみませんか?
質問タイム

More Related Content

OAuthで気持ちのいいアクセス制御を