「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
セキュリティに関する考察と、考慮点。
詳細 †
基礎 †
参考 †
- 第3回 Webセキュリティのおさらい
その3 CSRF・オープンリダイレクト・クリックジャッキング:
JavaScriptセキュリティの基礎知識|gihyo.jp … 技術評論社
認証に使用する †
問題点 †
認証ではなく認可のためのプロトコル(権限委譲プロトコル)である。
OAuth 2.0の仕様を熟読してもOAuth2.0を認証に使用しても問題ないように見える。
以下のBlogを参照して、
- 「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をAuthorization Codeに変更する。
- Implicitを利用している場合、Authorization Codeを利用できないか確認する。
- Authorization Codeであれば、Access Tokenの露見の可能性は低い(ただし、Clientの作り次第)。
拡張のフロー †
ベスト・プラクティス †
UserAgent?=SPA、スマホ
参考 †
OAuth 1.0 のほうが OAuth 2.0 より安全なの? †
qiita.com/TakahikoKawasaki? †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth