OAuth PKCE のバックアップ(No.3) - マイクロソフト系技術情報 Wiki

「マイクロソフト系技術情報 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文字列

#	パラメタ	要否	説明
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"を関連付ける方法は、仕様の対象外。

↑

参考 †

↑

仕様 †

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
https://tools.ietf.org/html/rfc7636

↑

その他 †

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