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

目次

概要

http://self-issued.info/?p=1959

と言った理由で、OAuth 2.0 Device Flowから変更された(v15から)。

前提

  1. Device(≒ Public Client)は、
    1. 既にインターネットに接続されている状態。
    2. アウトバウンドHTTPS要求を作成できる。
    3. EndUser?(≒ Resource Owner)にURIとコードを表示できる。
  2. EndUser?(≒ Resource Owner)は、
    セカンダリデバイス(PCやスマホなど)を持っている。

フロー

+----------+                                +----------------+
|          |>---(A)-- Client Identifier --->|                |
|          |                                |                |
|          |<---(B)-- Device Code,      ---<|                |
|          |          User Code,            |                |
|  Device  |          & Verification URI    |                |
|  Client  |                                |                |
|          |  [polling]                     |                |
|          |>---(E)-- Device Code,      --->|                |
|          |          & Client Identifier   |                |
|          |                                |  Authorization |
|          |<---(F)-- Access Token      ---<|     Server     |
+----------+   (& Optional Refresh Token)   |                |
      v                                     |                |
      :                                     |                |
     (C) User Code & Verification URI       |                |
      :                                     |                |
      v                                     |                |
+----------+                                |                |
| End user |                                |                |
|    at    |<---(D)-- End user reviews  --->|                |
|  Browser |          authorization request |                |
+----------+                                +----------------+
  1. ClientはAuthZ(N)Serverからの認可要求にclient_idを含める(A)。
  2. AuthZ(N)Serverは、Clientの認可要求に対して下記を応答する(B)。
    • デバイス・コード
    • エンドユーザ・コード
    • エンドユーザ検証URI
  3. Clientは、EndUser?(≒ Resource Owner)に(別のデバイス上の)User-Agentを使用し、
    エンドユーザ検証URIにアクセスしエンドユーザ・コードを入力するように指示(C)。

  4. User-Agent
    • AuthZ(N)ServerはUser-Agentを介しEndUser?(≒ Resource Owner)を認証。
    • 許可要求に同意した場合、User-Agentからエンドユーザ・コードを入力、AuthZ(N)Serverで検証(D)。
  5. Client
    AuthZ(N)Serverを繰り返しPolling(デバイス・コードとclient_id)(E)

  6. AuthZ(N)Serverは、
    Clientから提供されたデバイス・コードとclient_idを検証し、
    EndUser?(≒ Resource Owner)が、アクセスを、
    • 許可した場合はaccess_tokenで応答し、(F)
    • 拒否した場合はエラーを返す。

詳細

認可エンドポイント

認証リクエストを受け付けて直ちにレスポンスする(以後、非同期的に処理)。

認可リクエスト

  • ポイントは
    • POSTであること。
    • client_secretは不要。
  • リクエスト例
    POST /device_authorization HTTP/1.1
    Host: server.example.com
    Content-Type: application/x-www-form-urlencoded
    
    client_id=459691054427

認可レスポンス

  • パラメタ
  • device_code
    • 必須。
    • デバイス・コード(デバイスを検証するコード)。
    • 高いエントロピーを要求(GUID位の長さか?)
  • user_code
    • 必須。
    • エンドユーザー確認コード。
    • BCDFGHJKLMNPQRSTVWXZ(基数20)から8文字(XXXX-XXXX)
    • 9桁の有効数字(nnn-nnn-nnn)
  • validation_uri
    • 必須
    • 承認のエンドユーザー検証URI
    • 手動入力可能なように短く。
  • validation_uri_complete
    • オプション。
    • QueryString?にuser_codeを含むvalidation_uri
    • QRコードやNFCなどのURIでブラウザが開かれる方法を使用する。
  • expires_in
    • 必須
    • device_code、user_codeの有効期間(秒)。
  • interval
    • オプション。
    • Polling間隔
      最小の待機時間(秒)
      デフォルトは5(秒)
  • レスポンス例
    HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: no-store
    
    {
      "device_code": "GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS",
      "user_code": "WDJB-MJHT",
      "verification_uri": "https://example.com/device",
      "verification_uri_complete": "https://example.com/device?user_code=WDJB-MJHT",
      "expires_in": 1800,
      "interval": 5
    }

エラーの返却

POSTのJSON返却なので、Tokenエンドポイントのレスポンス(失敗)と同じ。

ユーザへの指示

Resource Owner(EndUser?)への指示。

  • user_code and verification_uri
  • verification_uri_complete (optional)

※ device_codeは、混乱を招くため、対話中に表示しない。

表示例

  • 「verification_uri」
    +-----------------------------------------------+
    |                                               |
    |  Using a browser on another device, visit:    |
    |  https://example.com/device                   |
    |                                               |
    |  And enter the code:                          |
    |  WDJB-MJHT                                    |
    |                                               |
    +-----------------------------------------------+
  • 「verification_uri」 and 「verification_uri_complete (by QR code)」
    +-------------------------------------------------+
    |                                                 |
    |  Scan the QR code, or using     +------------+  |
    |  a browser on another device,   |[_]..  . [_]|  |
    |  visit:                         | .  ..   . .|  |
    |  https://example.com/device     | . .  . ....|  |
    |                                 |.   . . .   |  |
    |  And enter the code:            |[_]. ... .  |  |
    |  WDJB-MJHT                      +------------+  |
    |                                                 |
    +-------------------------------------------------+
  • その他
  • テキスト読み上げオーディオ
  • Bluetooth Low Energy(BLE)による
    • 非ブラウザユーザーインタラクション(コンパニオンアプリの利用)
    • ただし、verification_uri以外の操作は使用の範囲外。

手順

  1. Resource Owner(EndUser?)は、AuthZ(N)Server の verification_uri(HTTPS)に移動、
  2. user_codeを入力し、AuthZ(N)Serverに送信(デバイス認可セッションの識別のため)
    ※ user_code入力画面への遷移前のサインアップ、追加のセキュリティ検証などの手順を追加可能。
  3. この後に表示される画面で、同意 / 拒否 を回答して、AuthZ(N)Serverに再送信。
  4. Device(≒ Public Client)はdevice_codeでTokenエンドポイントを継続的にPolling
    • ユーザーが対話を完了するか、
    • コードが期限切れになるか、
    • 別のエラーが発生するまで。

セキュリティ考慮事項

user_code入力の試行回数は、5回(アルファベットで8文字程度)。

Tokenエンドポイント

Tokenリクエスト

デバイス上のプロンプトに表示した後、TokenリクエストのPollingを始める。

  • パラメタ
    • grant_type=urn:ietf:params:oauth:grant-type:device_code
    • device_code
    • client_id
  • リクエスト例
    POST /token HTTP/1.1
    Host: server.example.com
    Content-Type: application/x-www-form-urlencoded
    
    grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code
    &device_code=GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS
    &client_id=459691054427

Tokenレスポンス

  • 成功
    OAuth 2.0の認可レスポンス(成功)と同じ。
  • 失敗
    OAuth 2.0の認可レスポンス(失敗)に以下のパラメタを追加
  • パラメタ(≒エラーコード)
  • authorization_pending
    認可リクエストは保留中
  • slow_down
    "authorization_pending"の変形で
    Polling間隔を5秒遅らせろの意味。
  • access_denied
    Resource Owner(EndUser?)は、承認要求を拒否。
  • expired_token
    device_codeの有効期限が切れ。
  • レスポンス例
    HTTP/1.1 400 Bad Request
    Content-Type: application/json;charset=UTF-8
    Cache-Control: no-store
    Pragma: no-cache
    
    {
      "error":"authorization_pending"
    }

ポイント

  • Pollingなので、
  • 自動的ではなく、デバイス上のプロンプトに
    表示された場合にのみデバイス認証要求~Pollingを開始するなど。
  • クライアント認証
    client_id と device_code(client_secret)

その他

メタデータ

  • grant_types_supported に urn:ietf:params:oauth:grant-type:device_code を追加。
  • エンドポイントとして、device_authorization_endpoint を追加。

セキュリティ考慮事項

  • Deviceは、Public Clientで、PKCEとの違いは、
    認可リクエストと実際の認可を行うデバイスが異なる事。
  • 認可を行うデバイスは信頼できるが、
    認可リクエスト、Tokenリクエストを行うデバイスの信頼性は微妙
  • なので、device_code を client_secret代替として使用する。
    (紐付けのタメのuser_codeは、実際の認可を行うデバイスから入力する)
  • 中間者攻撃
    • Device購入者は、Deviceと開発・販売元が信頼できると期待している。
    • これがハズれると、中間者攻撃が成立してしまうことがある。
  • フィッシング
    • e-mailやSMSで validation_uri_completeを使用すると、
      フィッシング攻撃が成立してしまうことがあるので使用しない。
  • device_code と user_codeの盗難
  • セッションスパイ
    ショルダーハッキングのような。ディスプレイでか過ぎとか無いよね。
  • ブートストラップ
    通信チャネルは、デバイスの近くでのみ有効なものを選択する(見る、聞く、BLE)。

参考

2019年8月にDraftからRFC化がされている。

内部リンク

OAuth 2.0 Device Flow

CIBA(Client Initiated Backchannel Authentication)


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


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