OAuth 2.0 セキュリティ関連トピックのバックアップ(No.4) - マイクロソフト系技術情報 Wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
OAuth 2.0 セキュリティ関連トピックへ行く。
- 1 (2018-11-22 (木) 10:27:03)
- 2 (2018-11-22 (木) 12:55:48)
- 3 (2018-12-18 (火) 11:08:28)
- 4 (2019-05-21 (火) 18:44:01)
- 5 (2019-07-08 (月) 11:21:32)
- 6 (2019-07-18 (木) 14:17:20)
- 7 (2019-12-06 (金) 16:03:50)
- 8 (2021-07-14 (水) 02:52:30)

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

戻る

目次 †

目次
概要
詳細
参考
- OAuth 1.0 のほうが OAuth 2.0 より安全なの？
- qiita.com/TakahikoKawasaki

概要 †

セキュリティに関する考察と、考慮点。

詳細 †

基礎 †

OAuth 2.0 Threat Model and Security Considerations †

参考 †

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/

認証に使用する †

問題点 †

認証ではなく認可のためのプロトコル（権限委譲プロトコル）である。
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が露見し得る。

このため、これらの問題がある状態で、OAuth 2.0を認証に使用すると、

「Resource Serverで公開しているリソースへのアクセスを認可する。」

という限られた権限より、（システムにログインできるということは）大きい権限を委譲することになるので、
この発言の背景では、「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。

対応方法１ †

従って、この問題は、特に脆弱なImplicit Flowを対象に、以下のように対策できる。

ImplicitをAuthorization Codeに変更する。
- Implicitを利用している場合、Authorization Codeを利用できないか確認する。
- Authorization Codeであれば、Access Tokenの露見の可能性は低い（ただし、Clientの作り次第）。

基本実装を拡張する。
- Bearer TokenをJWTアサーションに変更する。
- OAuth 2.0 拡張で
  - 追加のクライアント認証をサポートする。
  - 追加された仕様をサポートする。
- OpenID Connectをサポートする。

対応方法２ †

更に、昨今、Implicitフロー非推奨の流れが。

拡張のフロー †

スマホ向け †

デバイス向け †

ベスト・プラクティス †

UserAgentでOAuth2のTokenを取得するベスト・プラクティス †

UserAgent?＝SPA、スマホの意

OAuth 2.0 Security Best Current Practice †

最新のドラフト（で、Implicitフロー非推奨の動きが話題）。

参考 †

OAuth 1.0 のほうが OAuth 2.0 より安全なの？ †

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? †

OAuth 2.0 のフローとクライアントタイプの関係
https://qiita.com/TakahikoKawasaki/items/13a3e935b29cd9a997d6
OAuth 2.0 の認可レスポンスとリダイレクトに関する説明
https://qiita.com/TakahikoKawasaki/items/8567c80528da43c7e844

Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth