Token>#jb722a87]]を取得できる。--[[認可エンドポイント>#s820b1ab]]へ遷移する際にstateパラメタを付与する。--Redirectエンドポイントで[[stateパラメタ>#wbfa8d08]]をチェックする。認証に使うと、~車が通れる程どてかいセキュリティ・ホールが開く。Token>#jb722a87]]を収集する。Token>#jb722a87]]置き換え攻撃により、Client(B)経由でリソース・アクセスできる。Token>#jb722a87]]置き換え攻撃の問題とその対応方法-[[OAuth2.0を認証に使用する際の問題点とその対応方法>#add861ca]]が、ごちゃ混ぜになっていること。2.0は認証で使用できるが、以下の問題がある。[#pd85d22e]認証ではなく認可のためのプロトコル(権限委譲プロトコル)である。2.0の仕様を熟読してもOAuth2.0を認証に使用しても問題ないように見える。ありえるえりあ~http://dev.ariel-networks.com/wp/archives/258~--「OAuthが権限委譲(認可伝達)プロトコルなのは事実です。~・・・権限委譲プロトコルのひとつの利用方法に過ぎないからです。2.0の一利用方法と捉えることができる。2.0は認証で使用できる。2.0には以下の問題がある。Ownerから攻撃され得る。Serverに脆弱性があった場合、攻撃対象になり得る。Token>#jb722a87]]が露見し得る。Serverで公開しているリソースへのアクセスを認可する。」という限られた権限より、(システムにログインできるということは)大きい権限を委譲することになるので、~この発言の背景では、「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。2.0実装におけるToken置換攻撃の防ぎ方~http://d.hatena.ne.jp/ritou/20120702/1341235859以下のように対策できる。Codeを利用できないか確認する。Token>#jb722a87]]の露見の可能性は低い(ただし、Clientの作り次第)。Token>#jb722a87]]を発行する。Token>#jb722a87]]の内容を確認するAPI用意し、Clientからそれを叩く。--上記の処理は、RFCに定義は無いので独自に実装する必要がある。---Clientの確認には、[[クライアント識別子>#i7b73962]]を利用する。Token>#jb722a87]]の露見を検知でき、影響範囲を露見を起こしたClient範囲に絞ることができる。Agentで使用する場合、[[クライアント識別子>#i7b73962]]の露見のリスクもあるので注意が必要である。その他、新しい仕様も策定されている。Tokenを利用する。code」を実装する。code」を利用する。Possession」というドラフトがリリースされている。詳しくは、[[コチラ>OAuthによる外部ログイン(認証)の研究]]を参照。安全ではない」とは言えない。Clientを作る方こそ安全ではない。