OAuth PKCE のバックアップ(No.5)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• OAuth PKCE へ行く。
  • 1 (2017-11-20 (月) 15:58:22)
  • 2 (2017-11-20 (月) 18:33:46)
  • 3 (2017-11-24 (金) 18:53:22)
  • 4 (2017-11-30 (木) 13:40:36)
  • 5 (2017-12-01 (金) 10:24:15)
  • 6 (2017-12-08 (金) 09:38:54)
  • 7 (2017-12-14 (木) 15:58:36)
  • 8 (2017-12-18 (月) 22:47:26)
  • 9 (2018-02-16 (金) 16:17:08)
  • 10 (2018-02-16 (金) 19:59:52)
  • 11 (2018-02-22 (木) 18:53:54)
  • 12 (2018-03-06 (火) 12:59:57)
  • 13 (2018-03-19 (月) 15:15:47)
  • 14 (2018-03-23 (金) 18:13:44)
  • 15 (2018-10-09 (火) 22:15:45)
  • 16 (2018-11-10 (土) 22:47:30)
  • 17 (2019-02-05 (火) 21:08:04)
  • 18 (2019-03-20 (水) 17:15:09)
  • 19 (2019-03-26 (火) 10:45:53)
  • 20 (2019-04-11 (木) 10:51:09)
  • 21 (2019-07-17 (水) 09:44:06)
  • 22 (2019-07-18 (木) 14:25:21)
  • 23 (2019-11-14 (木) 18:38:46)
  • 24 (2019-11-21 (木) 18:52:47)
  • 25 (2020-01-06 (月) 18:47:21)
  • 26 (2020-02-22 (土) 18:21:38)

---

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

• 戻る

目次 †

概要 †

• 認可コード横取り攻撃 (authorization code interception attack) への対策

• （Authorization Codeグラント種別により発行された）
  認可コードをクライアントアプリケーションが受け取る際、
  悪意のあるアプリケーションがその認可コードを横取りする攻撃に対抗する仕様。

課題 †

ネイティブアプリが、外部ブラウザを使用してOAuth 2.0認証要求を発行する場合、

「Implicit Flowではなく、Authorization Code Flowを使用し、
redirect_uriにカスタムURIスキームを使用してcodeを取得する。」

という方式があるが（下図を参照）、

   +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
   | End Device (e.g., Smartphone)  |
   |                                |
   | +-------------+   +----------+ | (6) Access Token  +----------+
   | |Legitimate   |   | Malicious|<--------------------|          |
   | |OAuth 2.0 App|   | App      |-------------------->|          |
   | +-------------+   +----------+ | (5) Authorization |          |
   |        |    ^          ^       |        Grant      |          |
   |        |     \         |       |                   |          |
   |        |      \   (4)  |       |                   |          |
   |    (1) |       \  Authz|       |                   |          |
   |   Authz|        \ Code |       |                   |  Authz   |
   | Request|         \     |       |                   |  Server  |
   |        |          \    |       |                   |          |
   |        |           \   |       |                   |          |
   |        v            \  |       |                   |          |
   | +----------------------------+ |                   |          |
   | |                            | | (3) Authz Code    |          |
   | |     Operating System/      |<--------------------|          |
   | |         Browser            |-------------------->|          |
   | |                            | | (2) Authz Request |          |
   | +----------------------------+ |                   +----------+
   +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

• カスタムURIスキームの上書き攻撃によって、このcodeが傍受されることがある。
• また、client_idや、client_secretも漏洩してしまう可能性がある。

対策 †

• コード交換のための証明鍵（PKCE、 "pixy"と発音）を使用して脅威を軽減する。
• プロビジョニングされたアプリケーションのバイナリ・ファイル中のclient_secretについては、
  機密性が考慮されていないため、client_secretを必要としない方式になっている。

仕様 †

仕様の概要 †

このフローは、

• Client ≒ デバイス（UserAgent?）になる。

• Authorization Code Flowと同じだが、下記リクエストにパラメタが追加される。
  • 認証リクエスト
  • Tokenリクエスト

                                                +-------------------+
                                                |   Authz Server    |
      +--------+                                | +---------------+ |
      |        |--(A)- Authorization Request ---->|               | |
      |        |       + t(code_verifier), t_m  | | Authorization | |
      |        |                                | |    Endpoint   | |
      |        |<-(B)---- Authorization Code -----|               | |
      |        |                                | +---------------+ |
      | Client |                                |                   |
      |        |                                | +---------------+ |
      |        |--(C)-- Access Token Request ---->|               | |
      |        |          + code_verifier       | |    Token      | |
      |        |                                | |   Endpoint    | |
      |        |<-(D)------ Access Token ---------|               | |
      +--------+                                | +---------------+ |
                                                +-------------------+

仕様の詳細 †

• Clientは、認可リクエストを送信する前に、
  • 乱数 "code_verifier" を発生させ、
  • ハッシュ関数 "t" を用いた
  • ハッシュ値 "t(code_verifier)"を計算する。

• Clientは、認可リクエストに以下のパラメタを含める。
  • code_challenge_method：ハッシュ関数 "t"
  • code_challenge：ハッシュ値 "t(code_verifier)"

• 認可エンドポイントで、前述の認可リクエストを受信した際、これらを保存しておく。

• Clientは、Tokenリクエストに、先程生成した code_verifierパラメタを含める。

• Tokenエンドポイントでcode_verifierを含むTokenリクエストを受信した場合、保存されている
  • code_challenge_method：ハッシュ関数 "t"
  • code_challenge：ハッシュ値 "t(code_verifier)"

を使用して、code_verifierの妥当性を検証する。

• なお、このフローでは、client_secretは不要とする。

各エンドポイントで受け取るパラメタ †

• 認可エンドポイント

  #	パラメタ	要否	説明
  1	code_challenge	必須	Code Verifier を元に計算された Code Challenge の値
  2	code_challenge_method	任意	Code Challenge の計算に用いるハッシュ関数。 "plain"と"S256"があり、デフォルトは "plain"。

• Tokenエンドポイント

  #	パラメタ	要否	説明
  1	code_verifier	必須	動的に作成された暗号的にランダムな43-128文字以上のbase64url文字列

ハッシュ関数 †

• plain：
  • 恒等関数
  • code_verifierをそのまま使用する（ClientでS256がサポートできない場合）。
• S256：
  • BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
  • SHA-256 でハッシュ化した値を base64url に変換したもの。

codeとの関連 †

• サーバー・ステートレス
  通常、"code_challenge"および"code_challenge_method"の
  値は暗号化された形式で"code"自体に格納される。

• サーバー・ステートフル
  codeに関連付けられたAuthorization Serverに格納することもできるが、
  "code_challenge"と"code"を関連付ける方法は、仕様の対象外。

セキュリティに関する考慮事項 †

code_verifier †

• code_verifierには充分なエントロピーが必要（256ビット以上）。
• 生成には、適切なRNG（RNGCryptoServiceProvider?など）の使用が推奨される。

盗聴者からの保護 †

• 通常、"S256"を使用する。
  PKCEをサポートするサーバーは"S256"をサポートする必要がある。
  • "plain"では、"code_challenge" = "code_verifier"となり盗聴が可能。
  • 従って、通常、"plain"ではなく、"S256"を使用する必要がある。

• "plain"を使用する場合、

  サーバー・ステートレスで"code"から"code_challenge"および"code_challenge_method"を
  取り出す場合の処理は、当該サーバだけが可能になるように実装する必要がある。

code_challenge †

code_challengeの生成にソルト（やストレッチ）が不要な理由。

• ソルトによって、辞書空間が大幅に拡張される。
• しかし、
  • code_verifierはpasswordと異なり、エントロピーが高い。
  • GPUの進化によってソルトの価値が減ってきている。

このため、code_challengeの生成にソルト（やストレッチ）は不要。

参考 †

仕様 †

• RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
  https://tools.ietf.org/html/rfc7636
  • OAuth 2.0 Threat Model and Security Considerations
    https://www.rfc-editor.org/rfc/rfc6819.txt
  • Recommendations for Secure Use of
    Transport Layer Security (TLS)
    and Datagram Transport Layer Security (DTLS)
    https://www.rfc-editor.org/rfc/rfc7525.txt

その他 †

• RFC7636として発行されたOAuth PKCEとは - r-weblife
  http://d.hatena.ne.jp/ritou/20151018/1445181974

• PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと - Qiita
  https://qiita.com/TakahikoKawasaki/items/00f333c72ed96c4da659

• OAuth2.0で認可コードの漏洩を防ぐPKCE - 理系学生日記
  http://kiririmode.hatenablog.jp/entry/20170206/1486306800
  • OAuth 2.0 and PKCE | Pedro Félix's shared memory
    https://blog.pedrofelix.org/2016/02/15/oauth-2-0-and-pkce/

• OAuth for Native Apps | GREE Engineers' Blog
  http://labs.gree.jp/blog/2015/12/14831/
  • 解決策1-2: OAuth PKCE 拡張を利用する

---

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

     

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.030 sec.