![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>OAuth]] * 目次 [#y0a71766] #contents *概要 [#ic172116] セキュリティに関する考察と、考慮点。 *詳細 [#fa9e8ea2] **基礎 [#ad64edd6] ***[[OAuth 2.0 Threat Model and Security Considerations]] [#l35a960f] ***参考 [#re56087c] -slideshare.net --今更聞けないOAuth2.0 - セキュリティ対策~ http://www.slideshare.net/ph1ph2sa25/oauth20-46144252/54 --OAuth 2.0の概要とセキュリティ~ http://www.slideshare.net/charlier-shoe/oauth-20-29540466 -デジタルID最新動向（2） - ＠IT --「OAuth 2.0」の基本動作を知る~ http://www.atmarkit.co.jp/ait/articles/1708/31/news124.html --図解：OAuth 2.0に潜む「5つの脆弱性」と解決法~ http://www.atmarkit.co.jp/ait/articles/1710/24/news011.html -第3回 Webセキュリティのおさらい~ その3 CSRF・オープンリダイレクト・クリックジャッキング：~ JavaScriptセキュリティの基礎知識｜gihyo.jp … 技術評論社~ --http://gihyo.jp/dev/serial/01/javascript-security/0003?page=1 --http://gihyo.jp/dev/serial/01/javascript-security/0003?page=2 -HTTPS でも Full URL が漏れる？OAuth の Code も漏れるんじゃね？？~ http://oauth.jp/blog/2016/07/27/https-full-url-leaks/ **認証に使用する [#n58a4016] ***問題点 [#uafcfef2] 認証ではなく認可のためのプロトコル（権限委譲プロトコル）である。~ OAuth 2.0の仕様を熟読してもOAuth2.0を認証に使用しても問題ないように見える。 以下のBlogを参照して、 -認可のためのプロトコルのOAuthが認証に使えることの説明 | ありえるえりあ~ http://dev.ariel-networks.com/wp/archives/258~ --「OAuthが権限委譲(認可伝達)プロトコルなのは事実です。~ ・・・権限委譲プロトコルのひとつの利用方法に過ぎないからです。」 --「権限委譲プロトコルOAuthで、事実上、認証伝達ができる。」 の部分を見ると、全権限の認可は≒認証で、~ OAuth 2.0による認証も、OAuth 2.0の一利用方法と捉えることができる。 従って、「OAuth 2.0は認証で使用できる。」と考える。~ ただし、「OAuth 2.0には以下の問題がある。」と考える。 -Openな仕掛けで、インターネット上の野良Client、Resource Ownerから攻撃され得る。 -また、Authorization Serverに脆弱性があった場合、攻撃対象になり得る。 -さらに、Clientの作り次第で、[[Access Token>#jb722a87]]が露見し得る。 このため、これらの問題がある状態で、OAuth 2.0を認証に使用すると、 >「Resource Serverで公開しているリソースへのアクセスを認可する。」 という限られた権限より、（システムにログインできるということは）大きい権限を委譲することになるので、~ この発言の背景では、「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。 ***対応方法１ [#q5110fb8] 従って、この問題は、[[特に脆弱なImplicit Flow>OAuth 2.0 Threat Model (Implicit Flow)]]を対象に、以下のように対策できる。 -ImplicitをAuthorization Codeに変更する。 --Implicitを利用している場合、Authorization Codeを利用できないか確認する。 --Authorization Codeであれば、[[Access Token>#jb722a87]]の露見の可能性は低い（ただし、Clientの作り次第）。 -基本実装を拡張する。 --[[Bearer TokenをJWTアサーションに変更する。>JWTとOAuth2.0#y9c24d21]] --OAuth 2.0 拡張で ---[[追加のクライアント認証>#t68364d7]]をサポートする。 ---[[追加された仕様>#gc724ffd]]をサポートする。 --[[OpenID Connect]]をサポートする。 ***対応方法２ [#dd032533] 更に、昨今、[[Implicitフロー非推奨>#fefe0317]]の流れが。 **拡張のフロー [#l3509399] ***[[スマホ向け>OAuth 2.0 拡張#kf23d0ff]] [#rc141dde] ***[[デバイス向け>OAuth 2.0 拡張#u7974975]] [#jdaa8605] **ベスト・プラクティス [#iae908e9] ***[[UserAgentでOAuth2のTokenを取得するベスト・プラクティス]] [#a5ec04d6] UserAgent＝SPA、スマホの意 ***[[OAuth 2.0 Security Best Current Practice]] [#fefe0317] 最新のドラフト（で、Implicitフロー非推奨の動きが話題）。 *参考 [#o7c71667] **OAuth 1.0 のほうが OAuth 2.0 より安全なの？ [#xc90799f] -OAuth 1.0 のほうが OAuth 2.0 より安全なの？ - Qiita~ http://qiita.com/TakahikoKawasaki/items/3600b28af7b63671b968 --「OAuth 2.0 は OAuth 1.0 よりも安全ではない」とは言えない。 --OAuth 1.0 でClientを作る方こそ安全ではない。 --OAuth 1.0 ではなく OAuth 2.0 を採用するのが良い。 -OAuth 2.0 and the Road to Hell – hueniverse~ http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ **qiita.com/TakahikoKawasaki [#n6410be1] -OAuth 2.0 のフローとクライアントタイプの関係~ https://qiita.com/TakahikoKawasaki/items/13a3e935b29cd9a997d6 -OAuth 2.0 の認可レスポンスとリダイレクトに関する説明~ https://qiita.com/TakahikoKawasaki/items/8567c80528da43c7e844 ---- Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
