RFC 8628 - OAuth 2.0 Device Authorization Grant
- ステータス: Proposed Standard
- 発行日: August 2019
- ストリーム: IETF
- エラッタ: エラッタなし
Abstract
The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.
Table of Contents
- 1. Introduction
- 2. Terminology
- 3. Protocol
- 4. Discovery Metadata
- 5. Security Considerations
- 6. Usability Considerations
- 7. IANA Considerations
- 8. Normative References
- Acknowledgements
- Authors' Addresses
Copyright Notice: This document is subject to BCP 78 and the IETF Trust's Legal Provisions. For details, visit https://trustee.ietf.org/license-info.
3. Protocol
This section defines the core flows of the OAuth 2.0 Device Authorization Grant protocol, including device authorization requests, responses, user interaction, and token acquisition.
Section Navigation
- 3.1. Device Authorization Request: How device clients initiate authorization requests to the authorization server
- 3.2. Device Authorization Response: Verification codes and URIs returned by the authorization server
- 3.3. User Interaction: Authorization flow on the user's secondary device
- 3.3.1. Non-Textual Verification URI Optimization: Using QR codes and other non-textual methods
- 3.4. Device Access Token Request: Device client polling for access tokens
- 3.5. Device Access Token Response: Token endpoint responses and error handling
Protocol Overview
New Endpoint
This specification defines a new OAuth endpoint: the Device Authorization Endpoint, separate from the OAuth authorization endpoint defined in RFC 6749.
Key Differences
- Traditional OAuth: Users interact with the authorization server via browser
- Device Flow: Device clients communicate directly with the authorization server; users complete authorization on another device
Protocol Characteristics
- One-way Communication: No two-way communication required between device client and user agent
- Polling Mechanism: Clients continuously poll the authorization server for authorization results
- Separated Authorization: Authorization request and approval occur on different devices
Please refer to individual subsections for detailed technical specifications and implementation details.
5. Security Considerations
This section discusses security threats and corresponding mitigation measures for the OAuth 2.0 Device Authorization Grant.
Section Navigation
- 5.1. User Code Brute Forcing
- 5.2. Device Code Brute Forcing
- 5.3. Device Trustworthiness
- 5.4. Remote Phishing
- 5.5. Session Spying
- 5.6. Non-Confidential Clients
- 5.7. Non-Visual Code Transmission
Please refer to individual subsections for detailed threat analysis and protection measures.
7. IANA Considerations (IANA 考慮事項)
🇬🇧 English
This specification registers the following values in IANA registries.
7.1. OAuth Parameter Registration
This specification registers the following values in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749].
Name: device_code
Parameter Usage Location: token request
Change Controller: IESG
Reference: Section 3.4 of RFC 8628
Name: user_code
Parameter Usage Location: device authorization response
Change Controller: IESG
Reference: Section 3.2 of RFC 8628
Name: verification_uri
Parameter Usage Location: device authorization response
Change Controller: IESG
Reference: Section 3.2 of RFC 8628
Name: verification_uri_complete
Parameter Usage Location: device authorization response
Change Controller: IESG
Reference: Section 3.2 of RFC 8628
7.2. OAuth URI Registration
This specification registers the following values in the IANA "OAuth URI" registry [IANA.OAuth.Parameters] established by [RFC6755].
URN: urn:ietf:params:oauth:grant-type:device_code
Common Name: Device Authorization Grant Type for OAuth 2.0
Change Controller: IESG
Specification Document: Section 3.4 of RFC 8628
7.3. OAuth Extensions Error Registration
This specification registers the following values in the IANA "OAuth Extensions Error Registry" registry [IANA.OAuth.Parameters] established by [RFC6749].
authorization_pending
Name: authorization_pending
Usage Location: Token endpoint response
Protocol Extension: RFC 8628
Change Controller: IETF
Reference: Section 3.5 of RFC 8628
access_denied
Name: access_denied
Usage Location: Token endpoint response
Protocol Extension: RFC 8628
Change Controller: IETF
Reference: Section 3.5 of RFC 8628
slow_down
Name: slow_down
Usage Location: Token endpoint response
Protocol Extension: RFC 8628
Change Controller: IETF
Reference: Section 3.5 of RFC 8628
expired_token
Name: expired_token
Usage Location: Token endpoint response
Protocol Extension: RFC 8628
Change Controller: IETF
Reference: Section 3.5 of RFC 8628
7.4. OAuth Authorization Server Metadata
This specification registers the following values in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414].
Metadata name: device_authorization_endpoint
Metadata Description: URL of the authorization server's device authorization endpoint
Change Controller: IESG
Reference: Section 4 of RFC 8628
🇯🇵 日本語
本仕様は、IANA レジストリに以下の値を登録します。
7.1. OAuth パラメータ登録
本仕様は、[RFC6749] によって確立された IANA "OAuth Parameters" レジストリ [IANA.OAuth.Parameters] に以下の値を登録します。
名前: device_code
パラメータ使用場所: トークンリクエスト
変更管理者: IESG
参照: RFC 8628 のセクション 3.4
名前: user_code
パラメータ使用場所: デバイス認可レスポンス
変更管理者: IESG
参照: RFC 8628 のセクション 3.2
名前: verification_uri
パラメータ使用場所: デバイス認可レスポンス
変更管理者: IESG
参照: RFC 8628 のセクション 3.2
名前: verification_uri_complete
パラメータ使用場所: デバイス認可レスポンス
変更管理者: IESG
参照: RFC 8628 のセクション 3.2
7.2. OAuth URI 登録
この仕様は、[RFC6755] によって確立された IANA "OAuth URI" レジストリ [IANA.OAuth.Parameters] に以下の値を登録します。
URN: urn:ietf:params:oauth:grant-type:device_code
一般名: OAuth 2.0 用デバイス認可グラントタイプ
変更管理者: IESG
仕様文書: RFC 8628 のセクション 3.4
7.3. OAuth 拡張エラー登録
この仕様は、[RFC6749] によって確立された IANA "OAuth Extensions Error Registry" レジストリ [IANA.OAuth.Parameters] に以下の値を登録します。
authorization_pending (認可保留中)
名前: authorization_pending
使用場所: トークンエンドポイントレスポンス
プロトコル拡張: RFC 8628
変更管理者: IETF
参照: RFC 8628 のセクション 3.5
access_denied (アクセス拒否)
名前: access_denied
使用場所: トークンエンドポイントレスポンス
プロトコル拡張: RFC 8628
変更管理者: IETF
参照: RFC 8628 のセクション 3.5
slow_down (速度低下)
名前: slow_down
使用場所: トークンエンドポイントレスポンス
プロトコル拡張: RFC 8628
変更管理者: IETF
参照: RFC 8628 のセクション 3.5
expired_token (トークン期限切れ)
名前: expired_token
使用場所: トークンエンドポイントレスポンス
プロトコル拡張: RFC 8628
変更管理者: IETF
参照: RFC 8628 のセクション 3.5
7.4. OAuth 認可サーバーメタデータ
この仕様は、[RFC8414] によって確立された IANA "OAuth Authorization Server Metadata" レジストリ [IANA.OAuth.Parameters] に以下の値を登録します。
メタデータ名: device_authorization_endpoint
メタデータの説明: 認可サーバーのデバイス認可エンドポイントの URL
変更管理者: IESG
参照: RFC 8628 のセクション 4
RFC 8628 - セクション5-8概要
ドキュメントステータス説明
RFC 8628の残りのセクション(セクション5.1-8および付録)は長く詳細であるため、著作権で保護された原文コンテンツの大量の繰り返しを避けるため、このドキュメントはセクション概要と重要ポイントを提供します。
完全な公式英語原文: https://www.rfc-editor.org/rfc/rfc8628.txt
セクション5: セキュリティ考慮事項
5.1 User Code Brute Forcing (ユーザーコードブルートフォース)
重要ポイント:
- ユーザーコードは使いやすさ向上のため短く、したがってエントロピーが低い
- 推奨: サーバーはレート制限を実装すべき
- 推奨: 十分なエントロピーのコードを使用(例: 8文字base-20エンコード ≈ 34.5ビットエントロピー)
- レート制限と限定的な有効期間の組み合わせがブルートフォース攻撃を防ぐ
5.2 Device Code Brute Forcing (デバイスコードブルートフォース)
重要ポイント:
- デバイスコードはユーザーに表示されないため、高エントロピーを使用すべき
- デバイスコードを推測した攻撃者は認可を取得する可能性がある
5.3 Device Trustworthiness (デバイスの信頼性)
重要ポイント:
- 認可を要求するデバイスとユーザーが認可するデバイスは異なる
- 中間者攻撃の可能性を考慮する必要がある
- デバイス製造元と認可サーバーの信頼性に依存
5.4 Remote Phishing (リモートフィッシング)
重要ポイント:
- 攻撃者はメール等を通じてユーザーにコードを入力させる可能性がある
- 推奨: 認可プロセス中にデバイス所有権を確認
- verification_uri_complete最適化については、デバイス確認に特別な注意が必要
- ユーザーコードの有効期間はフィッシング攻撃を制限するために十分に短くすべき
5.5 Session Spying (セッション盗聴)
重要ポイント:
- 悪意のあるユーザーがデバイスインターフェースを物理的に盗み見る可能性がある
- デバイスはコードが観察される機会を減らすため、運用環境を考慮すべき
5.6 Non-Confidential Clients (非機密クライアント)
重要ポイント:
- デバイスクライアントは通常、認証情報の機密性を保持できない
- パブリッククライアントとみなすべきで、なりすまし攻撃に脆弱
- RFC6819セクション5.3.1とRFC8252セクション8.5、8.6を参照
5.7 Non-Visual Code Transmission (非視覚的コード伝送)
重要ポイント:
- ユーザーコードは非視覚的手段(例: 音声、Bluetooth)で伝送できる
- 推奨: 通信チャネルは近接アクセスに制限すべき
セクション6: ユーザビリティ考慮事項
6.1 User Code Recommendations (ユーザーコード推奨事項)
推奨形式:
- Base-20文字セット: "BCDFGHJKLMNPQRSTVWXZ" (母音除去、ランダムな単語生成を回避)
- 例: "WDJB-MJHT" (8有効文字、20^8エントロピー)
- 純数字: "019-450-730" (9桁数字、10^9エントロピー)
- 処理推奨: 大文字小文字非依存、ダッシュと句読点の自動除去
ベストプラクティス:
- 混同しやすい文字を避ける(0/O、1/l/I)
- モバイルデバイスでの入力の利便性を考慮
- A-Z以外のキーボード領域では、純数字コードを検討
6.2 Non-Browser User Interaction (非ブラウザユーザーインタラクション)
重要ポイント:
- 代替コード伝送方法を交渉可能
- 例: Bluetooth経由でコンパニオンアプリに伝送
- この仕様の範囲外だが、プロトコルはこのような拡張をサポート
セクション7: IANA考慮事項
7.1 OAuthパラメータ登録
登録されたパラメータ:
- device_code
- user_code
- verification_uri
- verification_uri_complete
7.2 OAuth URI登録
登録されたURI:
- urn:ietf:params:oauth:grant-type:device_code
7.3 OAuth拡張エラー登録
登録されたエラーコード:
- authorization_pending
- slow_down
- expired_token
7.4 OAuth認可サーバーメタデータ
新しいメタデータフィールド:
- device_authorization_endpoint
セクション8: 参考文献
8.1 規範的参考文献
- RFC2119 - キーワード定義
- RFC6749 - The OAuth 2.0 Authorization Framework
- RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
- RFC8174 - Ambiguity of Uppercase vs Lowercase
- RFC8259 - The JavaScript Object Notation (JSON) Data Interchange Format
- RFC8414 - OAuth 2.0 Authorization Server Metadata
- RFC8446 - The Transport Layer Security (TLS) Protocol Version 1.3
8.2 参考情報
- RFC6819 - OAuth 2.0 Threat Model and Security Considerations
- RFC7525 - Recommendations for Secure Use of TLS and DTLS
- RFC8252 - OAuth 2.0 for Native Apps
完全なRFCドキュメント: https://www.rfc-editor.org/rfc/rfc8628 発行日: 2019年8月 Standard Track: Standards Track