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

目次

概要

OAuth 2.0には、(主にセキュリティ強化のための)様々な拡張仕様がある。

拡張のフロー

以下のような拡張フローがある。

スマホ向けフロー

スマホ向けベストプラクティス (RFC 8252 ... OAuth 2.0 for Native Apps)

認可コード横取り攻撃への対抗策 (RFC 7636 ... OAuth PKCE)

その他のデバイス向けフロー

OAuth 2.0 Device Flow

  • 概要
    • 入力デバイスを持たないデバイスでOAuth2を行う場合のフロー。
    • 別のデバイスで入力を始めるための(C) User Code & Verification URI には、以下が使用できる。
      • QRコードやNFC、
      • e-mailやSMS(Remote Phishingに注意)
  • フロー
         +----------+                                +----------------+
         |          |>---(A)-- Client Identifier --->|                |
         |          |                                |                |
         |          |<---(B)-- Verification Code, --<|                |
         |          |              User Code,        |                |
         |          |         & Verification URI     |                |
         |  Device  |                                |                |
         |  Client  |         Client Identifier &    |                |
         |          |>---(E)-- Verification Code --->|                |
         |          |    polling...                  |                |
         |          |>---(E)-- Verification Code --->|                |
         |          |                                |  Authorization |
         |          |<---(F)-- Access Token --------<|     Server     |
         +----------+  (w/ Optional Refresh Token)   |                |
               v                                     |                |
               :                                     |                |
              (C) User Code & Verification URI       |                |
               :                                     |                |
               v                                     |                |
         +----------+                                |                |
         | End-user |                                |                |
         |    at    |<---(D)-- User authenticates -->|                |
         |  Browser |                                |                |
         +----------+                                +----------------+

新しい仕様

その他、新しい仕様も策定されている。

OAuth 2.0 拡張で追加された仕様

トークン取り消し (RFC 7009 ... Token Revocation)

トークン情報取得 (RFC 7662 ... Token Introspection)

各種クライアント認証

OpenID Connectで追加された仕様

応答タイプ (response_type)の追加

応答モード (response_mode)の新設

claimsリクエスト・パラメタ

認証コンテキストクラス

リクエスト・オブジェクト

JWT Secured Authorization Request (JAR)

Financial API (FAPI)で追加された仕様

JWTとOAuth2.0

セキュリティ

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

認証に使用する

問題点

認証ではなく認可のためのプロトコル(権限委譲プロトコル)である。
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で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 を採用するのが良い。

参考


Tags: :認証基盤, :クレームベース認証, :OAuth


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-05-09 (水) 09:33:24 (100d)