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

OAuthで気持ちのいいアクセス制御を
KousukeEbihara <ebihara@tejimaya.com>

Twitter 中毒の
みなさん
こんにちは

Twitter には
サードパーティの
色んなクライアントや
サービスがありますね

モバツイッター
http://movatwitter.jp/

モバツイッター
携帯電話から Twitter を利用するためのサイト
メール投稿がおこなえたり、連携している画像投稿サイトに投稿した画像を表示できたりなどの多彩な機能を備える

OpenEBI
http://openebi.com/

OpenEBI
位置情報を飛ばして自分のルートを描いていくサイト（拙作）
Twitter への同時投稿が可能

ヌイッター
http://nwitter.com/

ヌイッター
ヌいたら報告するためのTweetツール（意味がよくわからないけど）

ただし、
サービス終了済み

悪の親玉？
違法性？

「こういう風に」のリンクを辿ってみた
http://takagi-hiromitsu.jp/diary/20080217.html

これは、他サイトであるところの
「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 のアクセス制御が求められている
のではないでしょうか

そこで颯爽と登場したOAuth
Twitter の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. リクエストトークンの取得
アタシ
ツール
歳？
２３
まぁ今年で２４
彼氏？
まぁ
（中略）
いいから
トモのリソースに
アクセスさせて
みたいな
サイト
a. リクエストトークン要求
ツール
うーん……
ちょっと聞いてみるから
トモ連れてきてよ
b. リクエストトークン発行

2. ユーザの承認を得る
ツール
連れてきてやった
みたいな
c. ユーザをサービスプロバイダに案内する
あなた本物のトモさん？
本当にこの人にアクセスさせて大丈夫なんだね？
サイト
d. ユーザを認証し、同意を取る
トモさんがいいって言うなら仕方がない。
e. ユーザをコンシューマに案内する

3. アクセストークンの取得
リクエストトークンはあくまで承認を得るためのものなので、
リソースにアクセスするためには別のトークンを用いる。
サイト
アタシ
ツール
（中略）
トモのリソースに
アクセスさせて
みたいな
f. ユーザ承認済みのリクエスト
トークン付きでアクセストークン
要求
ツール
仕方がないなあ。
ほら、鍵だよ
g. リクエストトークンを検証
し、アクセストークンを発行

4. リソースへのアクセス
サイト
h. アクセストークンを使って
リソースを要求アクセス
ツール
i. アクセストークンを検証し、
リソースへのアクセスを認める

補足
トークン付きリクエストは署名される
HMAC-SHA1 (Twitter はこの方式のみ対応)
RSA-SHA1
PLAINTEXT (非署名)

なんかすごそうじゃん。じゃあとりあえずOAuth
使っておけばよさげだね

残念ながら、
OAuthのプロトコルには
Session Fixation 脆弱性
が存在します

OAuthに潜む脆弱性
2009/04/23(海老原の誕生日！)、ソーシャルエンジニアリングの手法によりセッションを固定化できるという脆弱性がレポートされる
ID, パスワードや各種トークンやシークレットを盗まれるといった類の脆弱性ではない
プロバイダ側で対策が可能である

どういう脆弱性か
通常のフロー
コンシューマの利用開始
リクエストトークンを発行
アクセストークンを
発行し、
リソースへアクセス
ユーザ
プロバイダにリダイレクト
コンシューマにリダイレクト

どういう脆弱性か
攻撃フロー
リクエストトークンを承認
ユーザ
承認されたリクエストトークンを使い、アクセストークンを
発行し、
リソースへアクセス
ユーザにURLを踏ませる
コンシューマの利用開始
リクエストトークンを発行
攻撃者
プロバイダにリダイレクト

対策方法
承認されてないリクエストトークンでアクセストークンを要求した時点でリクエストトークンを無効にする
アクセストークンの要求に回数制限を設ける
同じリクエストトークンを使用して複数箇所からアクセスがあったと思われる場合、リクエストトークンを無効にする
コールバック URL をパラメータから渡すのではなく、登録制にする
Twitter が採っている対策
コールバック URL を用いず、コンシューマが使うキーをユーザに手入力させる
Yammer が採っている対策

対策方法
ただし、OAuthプロトコル自体の修正はまだおこなわれていない
現在どう対策するべきか協議中
近々修正された仕様が公開されるとかどうとか
アイディアがあれば是非提案してみてください！

OpenPNE 3.1 と
OAuth

OpenPNE3 ではOAuth対応が求められている
OpenSocial
WebAPI
このWebAPIを利用したサードパーティ製ツールを増やしていきたいですね

OpenPNE3 のOAuth（仮）
管理画面から特定のアプリケーションを登録、認可（ほぼすべてのSNS内リソースへのアクセス許可）
SNS 全体に関わるアプリケーション：OpenSocialなど
コミュニティから特定のアプリケーションを登録、認可（コミュニティに関するSNS内リソースへのアクセス許可）
コミュニティに関わるアプリケーション：コミュニティ間のチャットなど
個人で特定のアプリケーションを登録、認可（その個人がアクセスできるSNS内リソースへのアクセス許可）

OpenPNE3 は
6月中旬リリース（予定）の 3.1.1 でOAuthに対応します

これでOAuthが
ぐっと身近に
なりますね！
6月中旬が待ち遠しいです！

でもOAuthって
なんだか
難しそう……

そんなことないです
（コンシューマは）

いろいろライブラリ
が揃っている

情報もそれなりに
出てきている

OAuthのプロトコルは
かなりシンプルなので、
ライブラリがなくても
割となんとかなりそうな
くらい敷居は低いはず

ということで、
Twitter もしくは
OpenPNE3 向けに
OAuthアプリ作って
みませんか？

質問タイム

http://www.tejimaya.com	839
http://www.slideshare.net	76
http://co3k.org	3
http://ad.pne.jp	2
http://74.125.153.132	1
http://webcache.googleusercontent.com	1
http://tejimayaform.pne.jp	1

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

by Kousuke Ebihara on Jun 22, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

7 Embeds 923

Statistics

OAuthã§æ°æã¡ã^®ããã¢ã¯ã»ã¹å¶å¾¡ã — Presentation Transcript

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

by Kousuke Ebihara on Jun 22, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

7 Embeds 923

Statistics

OAuthã§æ°æã¡ã®ãã ã¢ã¯ã»ã¹å¶å¾¡ã — Presentation Transcript

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

OAuthã§æ°æã¡ã^®ããã¢ã¯ã»ã¹å¶å¾¡ã — Presentation Transcript