OAuth 2.0 セキュリティ関連トピックのバックアップ(No.1) - マイクロソフト系技術情報 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 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で公開しているリソースへのアクセスを認可する。」

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

対応方法 †

従って、この問題は、

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の露見の可能性は低い（ただし、Clientの作り次第）。

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

参考 †

今更聞けないOAuth2.0 - セキュリティ対策
http://www.slideshare.net/ph1ph2sa25/oauth20-46144252/54

OAuth 2.0の概要とセキュリティ
http://www.slideshare.net/charlier-shoe/oauth-20-29540466

第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/

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

OAuth 2.0 の脅威モデルとセキュリティの考慮事項 (RFC 6819) †

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/

参考 †

OAuth & OpenID Connect 関連仕様まとめ - Qiita
https://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3

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