- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>OAuth]]
-[[戻る>OAuth 2.0]]
* 目次 [#y0a71766]
#contents
*概要 [#ic172116]
セキュリティに関する考察と、考慮点。
*詳細 [#fa9e8ea2]
**基礎 [#ad64edd6]
***[[OAuth 2.0 Threat Model and Security Considerations]] [#l35a960f]
***脅威モデルとセキュリティ考慮事項 [#l35a960f]
[[OAuth 2.0 Threat Model and Security Considerations]]
***参考 [#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
-GoogleのOAuth 2.0実装におけるToken置換攻撃の防ぎ方 - r-weblife~
http://d.hatena.ne.jp/ritou/20120702/1341235859
-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]
従って、この問題は、
***対応方法1 [#q5110fb8]
従って、この問題は、[[特に脆弱なImplicit Flow>OAuth 2.0 Threat Model (Implicit Flow)]]を対象に、以下のように対策できる。
-r-weblife
--OAuth 2.0 Implicit Flowをユーザー認証に利用する際のリスクと対策方法について #idcon~
http://d.hatena.ne.jp/ritou/20120206/1328484575
--GoogleのOAuth 2.0実装におけるToken置換攻撃の防ぎ方~
http://d.hatena.ne.jp/ritou/20120702/1341235859
以下のように対策できる。
-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]]をサポートする。
***対応方法2 [#dd032533]
更に、昨今、[[Implicitフロー非推奨>UserAgentでOAuth2のTokenを取得するベスト・プラクティス#c545761d]]の流れが。
**拡張のフロー [#l3509399]
***[[スマホ向け>OAuth 2.0 拡張#kf23d0ff]] [#rc141dde]
***[[デバイス向け>OAuth 2.0 拡張#u7974975]] [#jdaa8605]
**ベスト・プラクティス [#iae908e9]
***[[OAuth 2.0 Security Best Current Practice]] [#fefe0317]
***[[UserAgentでOAuth2のTokenを取得するベスト・プラクティス]] [#a5ec04d6]
UserAgent=SPA、スマホ
UserAgent=SPA、スマホの意
-[[OAuth 2.0 for Native Apps]]
-[[OAuth 2.0 for Browser-Based Apps]]
***[[JWTのコンテキストで何故かSessionとかCookieとか]] [#h6d1fb0e]
*参考 [#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
**r-weblife [#sd6e3945]
https://ritou.hatenablog.com/archive/category/Security
-OAuth 2.0 / OpenID Connectにおけるstate, nonce, PKCEの限界を意識する~
https://ritou.hatenablog.com/entry/2019/07/08/070000
----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]