なんとなく
OAuth怖いって
思ってる奴
ちょっと来い
~ OAuth 1.0編 2013/3
RITOU

読んでもらいたい人
 よくわからんけどOAuthは怖い！
 よくわからんけどやっぱりOAuthは信
用できない！
 オレが難読化だ！

つのる想い
 Twitterの騒ぎ、問題の本質が見えなく
なってる気がする
 Twitterが対応した場所？違うよね
 Serverの対応は既存のClientへの影
響も考えた応急処置
 Client Credentialの難読化？んなわけ
ない
 盛り上がるのは良いけど・・・

このスライドの内容
 OAuthの前提
 OAuth 1.0 実装のポイント

このスライドの目的
 ぼくがかんがえるおーおーすのかんど
ころを知ってもらいたい
 特に、仕様がアレな部分をどう実装す
るかを紹介したい
 まぁ、OAuth 1.0の時代はもう終わっ
てるけどな

OAuth 1.0
(2007-2012)
Obsoleted by OAuth 2.0

OAuth1.0の前提
突っ込みどころはあるにしても、とりあ
えずこんな前提で仕様は書かれてる
 TLS(HTTPSなリクエスト)は信用できる
 HTTPなAPIもあるよね。署名つけよう
 2007年とか2008年とかだからね

Client Credentialの扱い
クライアントアプリケーションが信頼性の低い組織の管
理下に置かれるケースは少なくない。例えばクライアン
トがデスクトップアプリケーションで、ソースコードや
実行形式のバイナリが公開されている場合、攻撃者が分
析のためにコピーをダウンロードし、クライアントクレ
デンシャルを見付けてしまう可能性がある。
そういった場合、サーバーはクライアントのアイデン
ティティを検証する際、クライアントクレデンシャルの
みを使うべきではない。可能であれば、IP アドレスのよ
うな他の要素も用いるべきである。
http://openid-foundation-japan.github.com/draft-
hammer-oauth-10.html#client_cred_sec

OAuth1.0の前提
突っ込みどころはあるにしても、とりあ
えずこんな前提で仕様は書かれてる
 TLS(HTTPSなリクエスト)は信用できる
 HTTPなAPIもあるよね。署名つけよう
 モバイル/デスクトップアプリのClient
Credentialは取得される可能性がある
 難読化の話はもういらん

初めにユーザーが絡む
フローの話をしよう
いわゆる3-legged OAuth, ユーザーの
アクセス許可が入るフロー
(2-leggedについては最後に)

OAuth 1.0のポイント
 Access Token( / Secret)の管理
 アクセス許可結果の受け渡し
 Client Credentialの管理

ちょっと余計なの
ついてるけどフローは
まぁこんな感じ
http://developer.yahoo.co.
jp/other/oauth/flow.html

実装の
ポイントを
後ろから
見ていく
http://developer.yahoo.co.
jp/other/oauth/flow.html

APIアクセスに必要な情報
 2組のCredentialで署名する必要あり
 Access Token/Secret
 Consumer Key / Secret

http://developer.yahoo.co.
jp/other/oauth/flow.html

Access Token / Secretを
取得するためには
 これまたいろいろ必要
 Request Token / Secet
ユーザーの同意を求めるために必
要なやつ
 OAuth Verifier
ユーザーが許可したあとに発行さ
れるやつ

http://developer.yahoo.co.
jp/other/oauth/flow.html

OAuth Verifierを
取得するためには
 ユーザーが許可した後にServerから
Clientへのリダイレクトなどによる受
け渡しが必要

OAuth Verifierを
正しく渡してもらうには
 ClientからServerへの戻り先の指定が
必要
 OAuth Callback
Request Token取得時に指定
Serverは事前登録されているもの
と一致するか検証

http://developer.yahoo.co.
jp/other/oauth/flow.html

Request Tokenを取得する
ためには
 Client Credentialsが必要
 Consumer Key / Secret

Request Tokenを取得する
ためには
 Client Credentialsが必要
 Consumer Key / Secret
Webアプリケーションでここが
守られていればALL Secure

Request Tokenを取得する
ためには
 Client Credentialsが必要
 Consumer Key / Secret
Webアプリケーションでここが
守られていればALL Secure
モバイル/デスクトップアプリで
は第3者に取得される可能性が
どうなるか？

？ Client
Credential
＋
渡されたパラ
メータ
を投げるとこ
ろが信頼でき
なくなる
http://developer.yahoo.co.
jp/other/oauth/flow.html

？ Client
Credential
＋
渡されたパラ
メータ
を投げるとこ
ろが信頼でき
なくなる
http://developer.yahoo.co.
jp/other/oauth/flow.html

OAuth Callback
の指定にはServer
の検証が入る。
ここで不正な値を
指定されないよう
に守るしかない。
http://developer.yahoo.co.
jp/other/oauth/flow.html

3legged OAuthで重要なこと
 Client Credentialが悪意のある誰かに
取得されても、OAuth Verifierが取得
されなければ、第3者にToken
Credentialが渡ることを防げる

Server/Clientが
やらないといけないこと
 ServerはOAuth
Verifierが悪意のあ
る第3者に渡らないように実装
 ClientはServerが提供する安全な方
法を利用する(しかない)

以上の観点から
Twitterの実装を考える
 OAuth
Verifierが悪意のある第3者
に渡るケースがある
 戻り先のURLが事前に指定してある
場合、Request Token取得時に任意
のURLを指定できる

Client Credentialを安全に
管理できないClient
 第3者が Request Tokenを取得できる
 戻り先のURLが事前に指定してある
場合、Request Token取得時に自分
のサーバーのURLを指定できる
OAuth Verifier取得できる
AccessToken/Secret取得できる
Write権限でDM送れる

それに加えて
 ユーザーのアクセス許可画面をスキッ
プできるオプションがある
 302でリダイレクトしてた
iframe内で画面表示なしで
OAuth Verifierを取得できた

Twitterの件のまとめ
 アクセス許可画面の省略がキモ！ではない
 ノークリックを実現でとどめをさされた
のは事実
 しかし、画面表示をしたところでユー
ザーが見逃したらやられるだろう感
 Client Credentialの秘匿も本質じゃない
 本質はやはりOAuth Callbackの扱い

2legged OAuth
 Server-Clientの2者なので2legged
 アプリケーションに紐づくデータにア
クセスする用途に利用されている
 Client Credentialのみで署名生成
モバイル/デスクトップアプリは…
┐(´～`；)┌

Server/Clientが
やらないといけないこと
 Serverは2legged OAuthの利用をWebア
プリのみに制限する
 Client登録時に指定させる
Webアプリかどうか
利用するAPIの指定でもいい
 Clientはモバイル/デスクトップアプリか
ら直接2legged OAuthを使わない
 どうしてもな場合はバックエンドのサー
バーを経由するなど(工夫が必要)

ここまでをまとめると
OAuth 1.0の
(というか2.0もなんだけど)
実装の良し悪しは
ServerのClient管理にかかってる

ServerのClient管理の話
 1プロジェクト、1Client Credentialは
よくない
 Webアプリとネイティブアプリで
Client Credential共有

ServerのClient管理の話
 1プロジェクト、n Client Credentials
の形式が良さそう
 Webアプリとネイティブアプリで
Client Credentialを分ける
 それぞれに利用させるAPIを制限
 プロジェクト内のユーザー識別子は
統一

ServerのClient管理の話
 OAuth Callbackの適切な制限が必要
 HTTPSなURLのフルパス（個人的に
はパラメータも固定）
 複数指定はできていいと思う

ServerのClient管理の話
 気を付ける部分
 リダイレクタ対策
パラメータ無視や前方一致
ドメイン単位の制限
 カスタムURIスキーム
重複、先勝ちなどの特性
“oob”使ってユーザーに手動で渡し
てもらうほうが良いかも

特にOAuthのServerを実装
する人たちは正しい知識を
得たうえで、
ユーザーとClientが安全にリ
ソースアクセスできるよう
な手段を提供するように努
力しましょう

今回はこれぐらいにしとく
 OAuth 2.0編もそのうち作る