認証に使うと、~車が通れる程どてかいセキュリティ・ホールが開く。Token>#jb722a87]]を収集する。Token>#jb722a87]]置き換え攻撃により、Client(B)経由でリソース・アクセスできる。Token>#jb722a87]]置き換え攻撃の問題-[[OAuth2.0を認証に使用する際の問題点とその対応方法>#add861ca]]が、ごちゃ混ぜになっていること。[#add861ca]認証ではなく認可のためのプロトコル(権限委譲プロトコル)である。2.0の仕様を良く読んでもOAuth2.0を認証に使用しても問題ないように見える。ありえるえりあ~http://dev.ariel-networks.com/wp/archives/258~>「OAuthが権限委譲(認可伝達)プロトコルなのは事実です。~・・・権限委譲プロトコルのひとつの利用方法に過ぎないからです。2.0の一利用方法と考えることができる。2.0には以下の問題があると考える。-Openな仕掛けで、インターネット上の野良Client、ResourcesOwnerから攻撃され得る。-また、AuthorizationServerに脆弱性があった場合、攻撃対象になり得る。Token>#jb722a87]]が露見し得る。2.0を認証に使用すると、>「ResourceServerで公開しているリソースへのアクセスを認可する。」という限られた権限より、大きい権限を委譲することになるので、この発言の背景では、~「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。demo~http://www.slideshare.net/ritou/idcon11-implicit-demo以下のように対策できる。Codeを利用できないか確認する。Token>#jb722a87]]が発行された対象のClientを確認できるAPIを提供する。Token>#jb722a87]]置き換え攻撃を検知できる(RFCに定義はないので独自実装する)。Tokenを利用する。安全ではない」とは言えない。Clientを作る方こそ安全ではない。2.0仕様には4つのフローが定義されている。~これらのフローのタイプを「グラント種別」と呼ばれる。マッシュアップ:サーバサイドマッシュアップ~https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html以下の様な「グラント種別」がある模様。