「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
http://self-issued.info/?p=1959
と言った理由で、OAuth 2.0 Device Flowから変更された(v15から)。
前提 †
- Device(≒ Public Client)は、
- 既にインターネットに接続されている状態。
- アウトバウンドHTTPS要求を作成できる。
- EndUser?(≒ Resource Owner)にURIとコードを表示できる。
- 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 | |
+----------+ +----------------+
- ClientはAuthZ(N)Serverからの認可リクエストにclient_idを含める(A)。
- AuthZ(N)Serverは、Clientの認可リクエストに対して下記を応答する(B)。
- デバイス・コード
- エンドユーザ・コード
- エンドユーザ検証URI
- Clientは、EndUser?(≒ Resource Owner)に(別のデバイス上の)User-Agentを使用し、
エンドユーザ検証URIにアクセスしエンドユーザ・コードを入力するように指示(C)。
- User-Agent
- AuthZ(N)ServerはUser-Agentを介しEndUser?(≒ Resource Owner)を認証。
- 許可リクエストに同意した場合、User-Agentからエンドユーザ・コードを入力、AuthZ(N)Serverで検証(D)。
- Client
AuthZ(N)Serverを繰り返しPolling(デバイス・コードとclient_id)(E)
- AuthZ(N)Serverは、
Clientから提供されたデバイス・コードとclient_idを検証し、
EndUser?(≒ Resource Owner)が、アクセスを、
- 許可した場合はaccess_tokenで応答し、(F)
- 拒否した場合はエラーを返す。
詳細 †
認可エンドポイント †
認証リクエストを受け付けて直ちにレスポンスする(以後、非同期的に処理)。
認可リクエスト †
- ポイントは
- POSTであること。
- client_secretは不要。
認可レスポンス †
- 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」 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以外の操作は仕様の範囲外。
手順 †
- Resource Owner(EndUser?)は、AuthZ(N)Server の verification_uri(HTTPS)に移動、
- user_codeを入力し、AuthZ(N)Serverに送信(デバイス認可セッションの識別のため)
※ user_code入力画面への遷移前のサインアップ、追加のセキュリティ検証などの手順を追加可能。
- この後に表示される画面で、同意 / 拒否 を回答して、AuthZ(N)Serverに再送信。
- 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
Tokenレスポンス †
- authorization_pending
認可リクエストは保留中
- slow_down
"authorization_pending"の変形で
Polling間隔を5秒遅らせろの意味。
- access_denied
Resource Owner(EndUser?)は、認可(承認)要求を拒否。
- expired_token
device_codeの有効期限が切れ。
ポイント †
- 自動的ではなく、デバイス上のプロンプトに表示された場合
にのみデバイス認可(承認)要求~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)。
フローがRedirect等で一連の動作として繋がっておらず、
TokenエンドポイントがPollingである点が共通的ではある。
しかし、他の共通点は少なく、殆ど、別物と言える。
- コチラ:
- デバイス(Client)
- AuthZ (AuthN) Server
- ユーザ(Resource Owner)
- CIBA
- オペレータ(+CD(Client))
- AuthZ (AuthN) Server
- ユーザ(Resource Owner)(+AD)
- クライアント認証として、client_idのみ利用
(client_secret は
device_codeで代替するので不要
Public Clientの場合もあるから使用しない)。
- 追加でdevice_code、user_codeが必須となっている。
(各、リクエスト・レスポンス間の紐付け的な意味で)
- device_code
・デバイスの特定の意味。
・client_secretの代替
- user_code
・ユーザへの指示における要求の認可(承認)の意味。
・validation_uri_completeを使用すれば、入力は省略できる。
- code や msg を使用して、ADへのプッシュ通知と応答の正当性を確認。
- auth_req_idでPolling(モードによってはclient_notification_tokenを使用)
- CIBAには存在せず、コチラでは必須。
- デバイスの特定のために使用する。
- CIBAのauth_req_idの様に、Pollingで使用する。
- CIBAではoptionalだったがコチラでは必須。
- CIBAでは「未認証AD」の応答入力用だが、
コチラでは、ユーザへの指示における要求の認可(承認)入力用
- CIBAではoptionalだったがコチラには無い。
(だたし、CIBA FAPI Profileでは必須となっている)
- 画面表示用
CIBAのオペレータからユーザに口頭 ,etc. で伝える。
- フロント or バック
- コチラ:フロントチャネル
- CIBA:バックチャネル
- ココまで書いて気が付いたが、本フロー、
何気に以下の延長のクライアント認証っぽい。
確かに、ユーザではなく、デバイス(クライアント)を認証している。
参考 †
2019年8月にDraftからRFC化がされている。
内部リンク †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth