OwnerはUserIDやPasswordを保持しているユーザやシステム。Grantについては[[コチラ>#i2483bc0]]。[#m875246b]準備-クライアント登録の方法についてはOAuthの仕様では定められていない。Serverに対してアプリ名やドメインなどを添えて自身を登録。Clientを登録する。IDでログイン」といったボタンで開始する。OwnerからAPIアクセス権限の付与を受ける。2.0とでフローは多少異なる。Tokenを取得する。2.0:Client識別情報をclient_idパラメータに含める。Tokenを認可済にする)。Serverへのアクセス権限付与を許可する。Clientにリダイレクトして戻す。-リダイレクトURLには、アクセス権限を示すトークンが含まれる。2.0では、Client特性により、2種類のトークン形式が存在する。Token使ってAPIにアクセス。Tokenは期限切れ、無効化されるまで利用可能。[#gc1850ca]既知の問題点を組み合わせた攻撃手法。以下の2つが組み合わさって成立する。OAuth.jp~http://oauth.jp/blog/2014/05/07/covert-redirect/--[[前述の対策を行う。パラメータをチェックする。徳丸浩の日記(2011-01-27)~http://www.tokumaru.org/d/20110127.htmlザックリ言って、-推奨される-CSRF対策の-推測困難な文字列--(ワンタイム性は必須ではない)と言うモノらしい。認証に使うと、車が通れる程どてかいセキュリティ・ホールが開く。Zone~https://www.sakimura.org/2012/02/1487/ザックリ言って、-攻撃者の構築したRP(A)は、access_tokenを収集する。置換え攻撃により、~RP(B)にログイン(若しくはRP(B)経由でリソース・アクセス)できる。demo~http://www.slideshare.net/ritou/idcon11-implicit-demo以下のように対策できる。Flowを利用できないか確認する。-認可サーバーがアクセストークンが発行された対象のクライアントを確認できるAPIを提供する。~これにより、アクセストークン置き換え攻撃を検知できる(RFCに定義はないので独自実装する)。Tokenを利用する。[#jf8e8e73]HTTPSはホスト名の部分だけ情報として渡し、~以後のパスやクエリストリング情報は暗号化される。従ってGETでも一応安全だが、-アクセスログに残る-ブラウザの履歴に残る-リファラーに残るという問題がある。従って、このグラント種別では、-基本的に、Browserから実行させてはいけない。-また、Webサーバで、W3Cログ等を出力させないようにする。IISならW3Cログの出力をカスタマイズできる。安全ではない」とは言えない。クライアントアプリケーションを作る方こそ安全ではない。