OAuth 2.0 拡張のバックアップ(No.7)

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

戻る

目次 †

目次
概要
拡張のフロー
- スマホ向けフロー
  - スマホ向けベストプラクティス (RFC 8252 ... OAuth 2.0 for Native Apps)
  - 認可コード横取り攻撃への対抗策 (RFC 7636 ... OAuth PKCE)
- その他のデバイス向けフロー
  - OAuth 2.0 Device Flow
新しい仕様
セキュリティ
- 認証に使用する
  - 問題点
  - 対応方法
- 参考
参考

↑

概要 †

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

↑

拡張のフロー †

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

↑

OAuth 2.0 Device Flow †

draft-ietf-oauth-device-flow - OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
https://tools.ietf.org/html/draft-ietf-oauth-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が認証に使えることの説明 | ありえるえりあ
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 を採用するのが良い。