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

目次

概要

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

詳細

基礎

脅威モデルとセキュリティ考慮事項

OAuth 2.0 Threat Model and Security Considerations

参考

  • slideshare.net

認証に使用する

問題点

認証ではなく認可のためのプロトコル(権限委譲プロトコル)である。
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で公開しているリソースへのアクセスを認可する。」

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

対応方法1

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

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

対応方法2

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

拡張のフロー

スマホ向け

デバイス向け

ベスト・プラクティス

OAuth 2.0 Security Best Current Practice

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

UserAgent?=SPA、スマホの意

JWTのコンテキストで何故かSessionとかCookieとか

参考

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 を採用するのが良い。

qiita.com/TakahikoKawasaki?

r-weblife

https://ritou.hatenablog.com/archive/category/Security


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-10-03 (日) 16:57:41 (929d)