[要約] RFC 8628は、OAuth 2.0デバイス認証グラントの仕様を定義しています。この仕様の目的は、リソース所有者がデバイスでの認証を行い、アクセストークンを取得するためのプロトコルを提供することです。
Internet Engineering Task Force (IETF) W. Denniss
Request for Comments: 8628 Google
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
M. Jones
Microsoft
H. Tschofenig
ARM Limited
August 2019
OAuth 2.0 Device Authorization Grant
OAuth 2.0デバイス認証付与
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.
OAuth 2.0デバイス承認付与は、ユーザーエージェントベースの承認を実行するためのブラウザーがないか、ユーザーが承認フロー中に認証するためにテキストを入力する必要がある程度に制限された入力であるインターネット接続デバイス用に設計されています非現実的。このようなデバイス（スマートTV、メディアコンソール、デジタル画像フレーム、プリンターなど）のOAuthクライアントは、別のデバイスのユーザーエージェントを使用して、保護されたリソースにアクセスするためのユーザー認証を取得できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8628.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8628で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Device Authorization Request . . . . . . . . . . . . . . 5
3.2. Device Authorization Response . . . . . . . . . . . . . . 7
3.3. User Interaction . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Non-Textual Verification URI Optimization . . . . . . 9
3.4. Device Access Token Request . . . . . . . . . . . . . . . 10
3.5. Device Access Token Response . . . . . . . . . . . . . . 11
4. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. User Code Brute Forcing . . . . . . . . . . . . . . . . . 12
5.2. Device Code Brute Forcing . . . . . . . . . . . . . . . . 13
5.3. Device Trustworthiness . . . . . . . . . . . . . . . . . 13
5.4. Remote Phishing . . . . . . . . . . . . . . . . . . . . . 14
5.5. Session Spying . . . . . . . . . . . . . . . . . . . . . 15
5.6. Non-Confidential Clients . . . . . . . . . . . . . . . . 15
5.7. Non-Visual Code Transmission . . . . . . . . . . . . . . 15
6. Usability Considerations . . . . . . . . . . . . . . . . . . 16
6.1. User Code Recommendations . . . . . . . . . . . . . . . . 16
6.2. Non-Browser User Interaction . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. OAuth Parameter Registration . . . . . . . . . . . . . . 17
7.2. OAuth URI Registration . . . . . . . . . . . . . . . . . 17
7.3. OAuth Extensions Error Registration . . . . . . . . . . . 18
7.4. OAuth Authorization Server Metadata . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
This OAuth 2.0 [RFC6749] protocol extension enables OAuth clients to request user authorization from applications on devices that have limited input capabilities or lack a suitable browser. Such devices include smart TVs, media consoles, picture frames, and printers, which lack an easy input method or a suitable browser required for traditional OAuth interactions. The authorization flow defined by this specification, sometimes referred to as the "device flow", instructs the user to review the authorization request on a secondary device, such as a smartphone, which does have the requisite input and browser capabilities to complete the user interaction.
このOAuth 2.0 [RFC6749]プロトコル拡張を使用すると、OAuthクライアントは、入力機能が制限されているか、適切なブラウザーがないデバイス上のアプリケーションにユーザー認証を要求できます。このようなデバイスには、スマートTV、メディアコンソール、額縁、プリンターなどがあり、簡単な入力方法や従来のOAuth対話に必要な適切なブラウザーがありません。この仕様で定義されている承認フローは、「デバイスフロー」と呼ばれることもあり、スマートフォンなどのセカンダリデバイスで承認リクエストを確認するようユーザーに指示します。このデバイスには、ユーザーの操作を完了するために必要な入力機能とブラウザ機能があります。 。
The device authorization grant is not intended to replace browser-based OAuth in native apps on capable devices like smartphones. Those apps should follow the practices specified in "OAuth 2.0 for Native Apps" [RFC8252].
デバイス認証の付与は、スマートフォンなどの対応デバイス上のネイティブアプリのブラウザベースのOAuthに代わるものではありません。これらのアプリは、「ネイティブアプリのOAuth 2.0」[RFC8252]で指定されているプラクティスに従う必要があります。
The operating requirements for using this authorization grant type are:
この許可付与タイプを使用するための操作要件は次のとおりです。
(1) The device is already connected to the Internet.
（1）デバイスは既にインターネットに接続されています。
(2) The device is able to make outbound HTTPS requests.
（2）デバイスは、アウトバウンドHTTPS要求を行うことができます。
(3) The device is able to display or otherwise communicate a URI and code sequence to the user.
（3）デバイスは、URIとコードシーケンスを表示するか、ユーザーに伝えることができます。
(4) The user has a secondary device (e.g., personal computer or smartphone) from which they can process the request.
（4）ユーザーがリクエストを処理できるセカンダリデバイス（パソコンやスマートフォンなど）を持っている。
As the device authorization grant does not require two-way communication between the OAuth client on the device and the user agent (unlike other OAuth 2 grant types, such as the authorization code and implicit grant types), it supports several use cases that cannot be served by those other approaches.
デバイス認証の付与は、デバイスのOAuthクライアントとユーザーエージェント間の双方向通信を必要としないため（認証コードや暗黙の付与タイプなど、他のOAuth 2付与タイプとは異なり）、これを使用できないいくつかのユースケースをサポートしますこれらの他のアプローチによって提供されます。
Instead of interacting directly with the end user's user agent (i.e., browser), the device client instructs the end user to use another computer or device and connect to the authorization server to approve the access request. Since the protocol supports clients that can't receive incoming requests, clients poll the authorization server repeatedly until the end user completes the approval process.
デバイスクライアントは、エンドユーザーのユーザーエージェント（ブラウザなど）と直接対話するのではなく、別のコンピューターまたはデバイスを使用して認証サーバーに接続し、アクセス要求を承認するようにエンドユーザーに指示します。このプロトコルは着信要求を受信できないクライアントをサポートするため、クライアントは、エンドユーザーが承認プロセスを完了するまで、承認サーバーに繰り返しポーリングします。
The device client typically chooses the set of authorization servers to support (i.e., its own authorization server or those of providers with which it has relationships). It is common for the device client to support only one authorization server, such as in the case of a TV application for a specific media provider that supports only that media provider's authorization server. The user may not yet have an established relationship with that authorization provider, though one can potentially be set up during the authorization flow.
デバイスクライアントは通常、サポートする承認サーバーのセットを選択します（つまり、独自の承認サーバーまたはそれと関係のあるプロバイダーの承認サーバー）。メディアプロバイダーの承認サーバーのみをサポートする特定のメディアプロバイダー向けのTVアプリケーションの場合など、デバイスクライアントがサポートする承認サーバーは1つだけです。ユーザーはまだ承認プロバイダーとの間に確立された関係を持っていない可能性がありますが、承認フロー中にセットアップされる可能性があります。
+----------+ +----------------+
| |>---(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 | |
+----------+ +----------------+
Figure 1: Device Authorization Flow
図1：デバイス認証フロー
The device authorization flow illustrated in Figure 1 includes the following steps:
図1に示されているデバイス認証フローには、次の手順が含まれています。
(A) The client requests access from the authorization server and includes its client identifier in the request.
（A）クライアントは許可サーバーからのアクセスを要求し、そのクライアントIDを要求に含めます。
(B) The authorization server issues a device code and an end-user code and provides the end-user verification URI.
（B）承認サーバーはデバイスコードとエンドユーザーコードを発行し、エンドユーザー検証URIを提供します。
(C) The client instructs the end user to use a user agent on another device and visit the provided end-user verification URI. The client provides the user with the end-user code to enter in order to review the authorization request.
（C）クライアントは、別のデバイスでユーザーエージェントを使用し、提供されたエンドユーザー検証URIにアクセスするようにエンドユーザーに指示します。クライアントは、承認リクエストを確認するために入力するエンドユーザーコードをユーザーに提供します。
(D) The authorization server authenticates the end user (via the user agent), and prompts the user to input the user code provided by the device client. The authorization server validates the user code provided by the user, and prompts the user to accept or decline the request.
（D）承認サーバーは、エンドユーザーを（ユーザーエージェントを介して）認証し、デバイスクライアントから提供されたユーザーコードを入力するようユーザーに求めます。承認サーバーは、ユーザーから提供されたユーザーコードを検証し、要求を受け入れるか拒否するかをユーザーに求めます。
(E) While the end user reviews the client's request (step D), the client repeatedly polls the authorization server to find out if the user completed the user authorization step. The client includes the device code and its client identifier.
（E）エンドユーザーがクライアントの要求を確認する間（ステップD）、クライアントは認証サーバーを繰り返しポーリングして、ユーザーがユーザー認証ステップを完了したかどうかを確認します。クライアントには、デバイスコードとそのクライアント識別子が含まれます。
(F) The authorization server validates the device code provided by the client and responds with the access token if the client is granted access, an error if they are denied access, or an indication that the client should continue to poll.
（F）承認サーバーは、クライアントから提供されたデバイスコードを検証し、クライアントにアクセスが許可されている場合はアクセストークンで応答し、アクセスが拒否された場合はエラー、またはクライアントがポーリングを続行する必要があることを示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This specification defines a new OAuth endpoint: the device authorization endpoint. This is separate from the OAuth authorization endpoint defined in [RFC6749] with which the user interacts via a user agent (i.e., a browser). By comparison, when using the device authorization endpoint, the OAuth client on the device interacts with the authorization server directly without presenting the request in a user agent, and the end user authorizes the request on a separate device. This interaction is defined as follows.
この仕様では、新しいOAuthエンドポイントであるデバイス認証エンドポイントを定義しています。これは、[RFC6749]で定義されているOAuth承認エンドポイントとは異なり、ユーザーはユーザーエージェント（ブラウザなど）を介して対話します。対照的に、デバイス認証エンドポイントを使用する場合、デバイスのOAuthクライアントはユーザーエージェントにリクエストを提示せずに認証サーバーと直接対話し、エンドユーザーは別のデバイスでリクエストを認証します。この相互作用は次のように定義されます。
The client initiates the authorization flow by requesting a set of verification codes from the authorization server by making an HTTP "POST" request to the device authorization endpoint.
クライアントは、デバイスの認証エンドポイントにHTTP "POST"リクエストを送信して、認証サーバーに一連の検証コードをリクエストすることで、認証フローを開始します。
The client makes a device authorization request to the device authorization endpoint by including the following parameters using the "application/x-www-form-urlencoded" format, per Appendix B of [RFC6749], with a character encoding of UTF-8 in the HTTP request entity-body:
クライアントは、[RFC6749]の付録Bにある「application / x-www-form-urlencoded」形式を使用し、UTF-8の文字エンコードで次のパラメータを含めることにより、デバイス認証エンドポイントにデバイス認証リクエストを行います。 HTTPリクエストのエンティティ本体：
client_id REQUIRED if the client is not authenticating with the authorization server as described in Section 3.2.1. of [RFC6749]. The client identifier as described in Section 2.2 of [RFC6749].
セクション3.2.1で説明されているように、クライアントが承認サーバーで認証を行っていない場合は、client_idが必要です。 [RFC6749]の。 [RFC6749]のセクション2.2に記載されているクライアント識別子。
scope OPTIONAL. The scope of the access request as defined by Section 3.3 of [RFC6749].
スコープオプション。 [RFC6749]のセクション3.3で定義されているアクセスリクエストの範囲。
For example, the client makes the following HTTPS request:
たとえば、クライアントは次のHTTPSリクエストを行います。
POST /device_authorization HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
client_id=1406020730&scope=example_scope
client_id = 1406020730＆scope = example_scope
All requests from the device MUST use the Transport Layer Security (TLS) protocol [RFC8446] and implement the best practices of BCP 195 [RFC7525].
デバイスからのすべての要求は、トランスポート層セキュリティ（TLS）プロトコル[RFC8446]を使用し、BCP 195 [RFC7525]のベストプラクティスを実装する必要があります。
Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server MUST ignore unrecognized request parameters. Request and response parameters MUST NOT be included more than once.
値なしで送信されたパラメーターは、リクエストから省略されたかのように扱わなければなりません（MUST）。承認サーバーは、認識されない要求パラメーターを無視する必要があります。リクエストとレスポンスのパラメーターは複数回含めることはできません。
The client authentication requirements of Section 3.2.1 of [RFC6749] apply to requests on this endpoint, which means that confidential clients (those that have established client credentials) authenticate in the same manner as when making requests to the token endpoint, and public clients provide the "client_id" parameter to identify themselves.
[RFC6749]のセクション3.2.1のクライアント認証要件は、このエンドポイントでのリクエストに適用されます。つまり、クライアントクレデンシャルを確立している機密クライアントは、トークンエンドポイントとパブリッククライアントにリクエストを行う場合と同じ方法で認証されます。 「client_id」パラメータを指定して、自分自身を識別します。
Due to the polling nature of this protocol (as specified in Section 3.4), care is needed to avoid overloading the capacity of the token endpoint. To avoid unneeded requests on the token endpoint, the client SHOULD only commence a device authorization request when prompted by the user and not automatically, such as when the app starts or when the previous authorization session expires or fails.
このプロトコルのポーリングの性質（セクション3.4で指定）により、トークンエンドポイントの容量が過負荷にならないように注意する必要があります。トークンエンドポイントでの不要なリクエストを回避するために、クライアントはユーザーのプロンプトでデバイス認証リクエストを開始する必要があります（アプリの起動時や前の認証セッションの期限切れや失敗時など）。
In response, the authorization server generates a unique device verification code and an end-user code that are valid for a limited time and includes them in the HTTP response body using the "application/json" format [RFC8259] with a 200 (OK) status code. The response contains the following parameters:
それに応じて、認証サーバーは、一定期間有効な一意のデバイス検証コードとエンドユーザーコードを生成し、「application / json」形式[RFC8259]を使用してHTTP応答本文に200（OK）を含めてそれらを含めますステータスコード。応答には次のパラメーターが含まれます。
device_code REQUIRED. The device verification code.
device_codeが必要です。デバイス確認コード。
user_code REQUIRED. The end-user verification code.
user_codeが必要です。エンドユーザー確認コード。
verification_uri REQUIRED. The end-user verification URI on the authorization server. The URI should be short and easy to remember as end users will be asked to manually type it into their user agent.
validation_uriが必要です。承認サーバー上のエンドユーザー検証URI。エンドユーザーはユーザーエージェントに手動で入力するよう求められるため、URIは短く、覚えやすいものにする必要があります。
verification_uri_complete OPTIONAL. A verification URI that includes the "user_code" (or other information with the same function as the "user_code"), which is designed for non-textual transmission.
validation_uri_complete OPTIONAL。非テキスト送信用に設計された「user_code」（または「user_code」と同じ機能を持つ他の情報）を含む検証URI。
expires_in REQUIRED. The lifetime in seconds of the "device_code" and "user_code".
expires_inは必須です。 「device_code」と「user_code」の寿命（秒単位）。
interval OPTIONAL. The minimum amount of time in seconds that the client SHOULD wait between polling requests to the token endpoint. If no value is provided, clients MUST use 5 as the default.
間隔はオプションです。トークンエンドポイントへのポーリングリクエストの間にクライアントが待機する最小時間（秒単位）。値が提供されない場合、クライアントはデフォルトとして5を使用する必要があります。
For example:
例えば：
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
}
In the event of an error (such as an invalidly configured client), the authorization server responds in the same way as the token endpoint specified in Section 5.2 of [RFC6749].
エラー（無効に構成されたクライアントなど）が発生した場合、承認サーバーは[RFC6749]のセクション5.2で指定されたトークンエンドポイントと同じように応答します。
After receiving a successful authorization response, the client displays or otherwise communicates the "user_code" and the "verification_uri" to the end user and instructs them to visit the URI in a user agent on a secondary device (for example, in a browser on their mobile phone) and enter the user code.
成功した認証応答を受信した後、クライアントは「user_code」と「verification_uri」を表示するか、エンドユーザーに通信し、セカンダリデバイスのユーザーエージェントのURI（たとえば、ブラウザ）にアクセスするように指示します携帯電話）とユーザーコードを入力します。
+-----------------------------------------------+
| |
| Using a browser on another device, visit: |
| https://example.com/device |
| |
| And enter the code: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
Figure 2: Example User Instruction
図2：ユーザー指示の例
The authorizing user navigates to the "verification_uri" and authenticates with the authorization server in a secure TLS-protected [RFC8446] session. The authorization server prompts the end user to identify the device authorization session by entering the "user_code" provided by the client. The authorization server should then inform the user about the action they are undertaking and ask them to approve or deny the request. Once the user interaction is complete, the server instructs the user to return to their device.
認証ユーザーは「verification_uri」に移動し、安全なTLSで保護された[RFC8446]セッションで認証サーバーを使用して認証します。承認サーバーは、クライアントから提供された「user_code」を入力して、デバイス承認セッションを識別するようにエンドユーザーに要求します。承認サーバーは、ユーザーが実行しているアクションについてユーザーに通知し、リクエストを承認または拒否するように依頼する必要があります。ユーザーの操作が完了すると、サーバーはユーザーにデバイスに戻るように指示します。
During the user interaction, the device continuously polls the token endpoint with the "device_code", as detailed in Section 3.4, until the user completes the interaction, the code expires, or another error occurs. The "device_code" is not intended for the end user directly; thus, it should not be displayed during the interaction to avoid confusing the end user.
ユーザーの操作中、デバイスは、ユーザーが操作を完了するか、コードが期限切れになるか、別のエラーが発生するまで、セクション3.4で詳しく説明されているように、「device_code」を使用してトークンエンドポイントを継続的にポーリングします。 「device_code」は、エンドユーザーを直接対象としたものではありません。したがって、エンドユーザーの混乱を避けるために、対話中に表示しないでください。
Authorization servers supporting this specification MUST implement a user-interaction sequence that starts with the user navigating to "verification_uri" and continues with them supplying the "user_code" at some stage during the interaction. Other than that, the exact sequence and implementation of the user interaction is up to the authorization server; for example, the authorization server may enable new users to sign up for an account during the authorization flow or add additional security verification steps.
この仕様をサポートする承認サーバーは、ユーザーが「verification_uri」に移動して開始し、対話中のある段階で「user_code」を提供し続けるユーザー対話シーケンスを実装する必要があります。それ以外は、ユーザーインタラクションの正確なシーケンスと実装は承認サーバー次第です。たとえば、承認サーバーでは、新しいユーザーが承認フロー中にアカウントにサインアップしたり、セキュリティ検証手順を追加したりできます。
It is NOT RECOMMENDED for authorization servers to include the user code ("user_code") in the verification URI ("verification_uri"), as this increases the length and complexity of the URI that the user must type. While the user must still type a similar number of characters with the "user_code" separated, once they successfully navigate to the "verification_uri", any errors in entering the code can be highlighted by the authorization server to improve the user experience. The next section documents the user interaction with "verification_uri_complete", which is designed to carry both pieces of information.
承認サーバーにユーザーコード（ "user_code"）を検証URI（ "verification_uri"）に含めることはお勧めしません。これにより、ユーザーが入力する必要があるURIの長さと複雑さが増します。ユーザーは「user_code」を区切って同様の数の文字を入力する必要がありますが、「verification_uri」に正常に移動すると、認証サーバーによってコードの入力エラーを強調表示して、ユーザーエクスペリエンスを向上させることができます。次のセクションでは、両方の情報を伝えるように設計された「verification_uri_complete」とのユーザーインタラクションについて説明します。
When "verification_uri_complete" is included in the authorization response (Section 3.2), clients MAY present this URI in a non-textual manner using any method that results in the browser being opened with the URI, such as with QR (Quick Response) codes or NFC (Near Field Communication), to save the user from typing the URI.
「verification_uri_complete」が認証応答（セクション3.2）に含まれている場合、クライアントは、QR（Quick Response）コードなどのURIでブラウザーが開かれる任意の方法を使用して、このURIをテキスト以外の方法で提示できます（MAY）。 NFC（Near Field Communication）。ユーザーがURIを入力するのを防ぎます。
For usability reasons, it is RECOMMENDED for clients to still display the textual verification URI ("verification_uri") for users who are not able to use such a shortcut. Clients MUST still display the "user_code", as the authorization server will require the user to confirm it to disambiguate devices or as remote phishing mitigation (see Section 5.4).
使いやすさの理由から、このようなショートカットを使用できないユーザー向けに、テキストによる検証URI（ "verification_uri"）を引き続き表示することをクライアントに推奨します。承認サーバーはユーザーにデバイスの曖昧さをなくすために確認を要求するため、またはリモートフィッシングの緩和策として（セクション5.4を参照）、クライアントは引き続き「user_code」を表示する必要があります。
If the user starts the user interaction by navigating to "verification_uri_complete", then the user interaction described in Section 3.3 is still followed, with the optimization that the user does not need to type in the "user_code". The server SHOULD display the "user_code" to the user and ask them to verify that it matches the "user_code" being displayed on the device to confirm they are authorizing the correct device. As before, in addition to taking steps to confirm the identity of the device, the user should also be afforded the choice to approve or deny the authorization request.
ユーザーが「verification_uri_complete」に移動してユーザーインタラクションを開始した場合でも、セクション3.3で説明されているユーザーインタラクションが引き続き行われ、ユーザーが「user_code」を入力する必要がない最適化が行われます。サーバーはユーザーに「user_code」を表示し、正しいデバイスを承認していることを確認するために、デバイスに表示されている「user_code」と一致することを確認するようにユーザーに要求する必要があります（SHOULD）。以前と同様に、ユーザーはデバイスのIDを確認する手順を実行するだけでなく、承認リクエストを承認するか拒否するかを選択できる必要があります。
+-------------------------------------------------+
| |
| Scan the QR code or, using +------------+ |
| a browser on another device, |[_].. . [_]| |
| visit: | . .. . .| |
| https://example.com/device | . . . ....| |
| |. . . . | |
| And enter the code: |[_]. ... . | |
| WDJB-MJHT +------------+ |
| |
+-------------------------------------------------+
Figure 3: Example User Instruction with QR Code Representation of the Complete Verification URI
図3：完全な検証URIのQRコード表現を含むユーザー指示の例
After displaying instructions to the user, the client creates an access token request and sends it to the token endpoint (as defined by Section 3.2 of [RFC6749]) with a "grant_type" of "urn:ietf:params:oauth:grant-type:device_code". This is an extension grant type (as defined by Section 4.5 of [RFC6749]) created by this specification, with the following parameters:
ユーザーに指示を表示した後、クライアントはアクセストークンリクエストを作成し、「[grant_type]」が「urn：ietf：params：oauth：grant-type」のトークンエンドポイント（[RFC6749]のセクション3.2で定義）に送信します：device_code "。これは、この仕様によって作成された拡張許可タイプ（[RFC6749]のセクション4.5で定義）であり、次のパラメーターがあります。
grant_type REQUIRED. Value MUST be set to "urn:ietf:params:oauth:grant-type:device_code".
grant_typeは必須です。値は「urn：ietf：params：oauth：grant-type：device_code」に設定する必要があります。
device_code REQUIRED. The device verification code, "device_code" from the device authorization response, defined in Section 3.2.
device_codeが必要です。セクション3.2で定義されている、デバイス認証応答からのデバイス検証コード「device_code」。
client_id REQUIRED if the client is not authenticating with the authorization server as described in Section 3.2.1. of [RFC6749]. The client identifier as described in Section 2.2 of [RFC6749].
セクション3.2.1で説明されているように、クライアントが承認サーバーで認証を行っていない場合は、client_idが必要です。 [RFC6749]の。 [RFC6749]のセクション2.2に記載されているクライアント識別子。
For example, the client makes the following HTTPS request (line breaks are for display purposes only):
たとえば、クライアントは次のHTTPS要求を行います（改行は表示目的のみです）。
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=1406020730
grant_type = urn％3Aietf％3Aparams％3Aoauth％3Agrant-type％3Adevice_code＆device_code = GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS＆client_id = 1406020730
If the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1 of [RFC6749]. Note that there are security implications of statically distributed client credentials; see Section 5.6.
[RFC6749]のセクション3.2.1で説明されているように、クライアントにクライアント認証情報が発行された（または他の認証要件が割り当てられた）場合、クライアントは承認サーバーで認証する必要があります。静的に分散されたクライアント資格情報にはセキュリティの影響があることに注意してください。セクション5.6を参照してください。
The response to this request is defined in Section 3.5. Unlike other OAuth grant types, it is expected for the client to try the access token request repeatedly in a polling fashion based on the error code in the response.
このリクエストへの応答はセクション3.5で定義されています。他のOAuth付与タイプとは異なり、クライアントは、応答のエラーコードに基づいて、ポーリング方式でアクセストークン要求を繰り返し試行することが期待されています。
If the user has approved the grant, the token endpoint responds with a success response defined in Section 5.1 of [RFC6749]; otherwise, it responds with an error, as defined in Section 5.2 of [RFC6749].
ユーザーが許可を承認した場合、トークンエンドポイントは[RFC6749]のセクション5.1で定義された成功応答で応答します。それ以外の場合は、[RFC6749]のセクション5.2で定義されているように、エラーで応答します。
In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specified for use with the device authorization grant in token endpoint responses:
[RFC6749]のセクション5.2で定義されているエラーコードに加えて、次のエラーコードは、トークンエンドポイントの応答でデバイス許可付与で使用するために指定されています。
authorization_pending The authorization request is still pending as the end user hasn't yet completed the user-interaction steps (Section 3.3). The client SHOULD repeat the access token request to the token endpoint (a process known as polling). Before each new request, the client MUST wait at least the number of seconds specified by the "interval" parameter of the device authorization response (see Section 3.2), or 5 seconds if none was provided, and respect any increase in the polling interval required by the "slow_down" error.
authorization_pendingエンドユーザーがまだユーザーインタラクションの手順を完了していないため（セクション3.3）、承認リクエストはまだ保留中です。クライアントは、トークンエンドポイントへのアクセストークン要求を繰り返す必要があります（ポーリングと呼ばれるプロセス）。新しい各リクエストの前に、クライアントは、少なくともデバイス認証応答の「間隔」パラメーターで指定された秒数（セクション3.2を参照）、または何も指定されていない場合は5秒待機し、必要なポーリング間隔の増加を尊重する必要があります。 「slow_down」エラーによる。
slow_down A variant of "authorization_pending", the authorization request is still pending and polling should continue, but the interval MUST be increased by 5 seconds for this and all subsequent requests.
slow_down「authorization_pending」のバリアント。認証リクエストはまだ保留中であり、ポーリングは継続する必要がありますが、このリクエストと後続のすべてのリクエストの間隔は5秒増やす必要があります。
access_denied The authorization request was denied.
access_denied承認リクエストが拒否されました。
expired_token The "device_code" has expired, and the device authorization session has concluded. The client MAY commence a new device authorization request but SHOULD wait for user interaction before restarting to avoid unnecessary polling.
expired_token「device_code」が期限切れになり、デバイス認証セッションが終了しました。クライアントは新しいデバイス認証リクエストを開始してもよいですが、不必要なポーリングを回避するために再起動する前にユーザーの操作を待つ必要があります。
The "authorization_pending" and "slow_down" error codes define particularly unique behavior, as they indicate that the OAuth client should continue to poll the token endpoint by repeating the token request (implementing the precise behavior defined above). If the client receives an error response with any other error code, it MUST stop polling and SHOULD react accordingly, for example, by displaying an error to the user.
「authorization_pending」および「slow_down」エラーコードは、OAuthクライアントがトークンリクエストを繰り返すことによりトークンエンドポイントをポーリングし続ける必要があることを示すため、特に一意の動作を定義します（上記で定義された正確な動作を実装）。クライアントが他のエラーコードを含むエラー応答を受信した場合、クライアントはポーリングを停止する必要があり（SHOULD）、たとえば、ユーザーにエラーを表示することによって、それに応じて対応する必要があります。
On encountering a connection timeout, clients MUST unilaterally reduce their polling frequency before retrying. The use of an exponential backoff algorithm to achieve this, such as doubling the polling interval on each such connection timeout, is RECOMMENDED.
接続タイムアウトが発生した場合、クライアントは再試行する前に一方的にポーリング頻度を減らす必要があります。このような接続タイムアウトごとにポーリング間隔を2倍にするなど、指数バックオフアルゴリズムを使用してこれを実現することをお勧めします。
The assumption of this specification is that the separate device on which the user is authorizing the request does not have a way to communicate back to the device with the OAuth client. This protocol only requires a one-way channel in order to maximize the viability of the protocol in restricted environments, like an application running on a TV that is only capable of outbound requests. If a return channel were to exist for the chosen user-interaction interface, then the device MAY wait until notified on that channel that the user has completed the action before initiating the token request (as an alternative to polling). Such behavior is, however, outside the scope of this specification.
この仕様の前提は、ユーザーがリクエストを承認している別のデバイスには、OAuthクライアントを使用してデバイスに通信する方法がないことです。このプロトコルは、発信要求のみが可能なTVで実行されているアプリケーションなど、制限された環境でプロトコルの実行可能性を最大化するために一方向チャネルのみを必要とします。選択したユーザーインタラクションインターフェースにリターンチャネルが存在する場合、デバイスは、ユーザーがトークンリクエストを開始する前に（ポーリングの代わりに）アクションを完了したことをそのチャネルで通知されるまで待機できます（MAY）。ただし、このような動作はこの仕様の範囲外です。
Support for this protocol is declared in OAuth 2.0 Authorization Server Metadata [RFC8414] as follows. The value "urn:ietf:params:oauth:grant-type:device_code" is included in values of the "grant_types_supported" key, and the following new key value pair is added:
このプロトコルのサポートは、OAuth 2.0 Authorization Server Metadata [RFC8414]で次のように宣言されています。値「urn：ietf：params：oauth：grant-type：device_code」は「grant_types_supported」キーの値に含まれ、次の新しいキーと値のペアが追加されます。
device_authorization_endpoint OPTIONAL. URL of the authorization server's device authorization endpoint, as defined in Section 3.1.
device_authorization_endpointオプション。セクション3.1で定義されている、許可サーバーのデバイス許可エンドポイントのURL。
Since the user code is typed by the user, shorter codes are more desirable for usability reasons. This means the entropy is typically less than would be used for the device code or other OAuth bearer token types where the code length does not impact usability. Therefore, it is recommended that the server rate-limit user code attempts.
ユーザーコードはユーザーが入力するので、使いやすさの理由からコードは短い方が望ましいです。つまり、エントロピーは通常、デバイスコードや、コードの長さがユーザビリティに影響を与えないその他のOAuthベアラートークンタイプに使用されるエントロピーよりも小さくなります。したがって、サーバーでユーザーコードの試行を制限することをお勧めします。
The user code SHOULD have enough entropy that, when combined with rate-limiting and other mitigations, a brute-force attack becomes infeasible. For example, it's generally held that 128-bit symmetric keys for encryption are seen as good enough today because an attacker has to put in 2^96 work to have a 2^-32 chance of guessing correctly via brute force. The rate-limiting and finite lifetime on the user code place an artificial limit on the amount of work an attacker can "do". If, for instance, one uses an 8-character base 20 user code (with roughly 34.5 bits of entropy), the rate-limiting interval and validity period would need to only allow 5 attempts in order to get the same 2^-32 probability of success by random guessing.
ユーザーコードには十分なエントロピーがあり、レート制限や他の緩和策と組み合わせると、ブルートフォース攻撃が実行不可能になります。たとえば、攻撃者がブルートフォースで2 ^ -32の確率で正確に推測できるようにするには、攻撃者が2 ^ 96の作業を行わなければならないため、暗号化用の128ビット対称キーは今日では十分であると一般に考えられています。ユーザーコードのレート制限と有限のライフタイムは、攻撃者が「実行」できる作業量に人為的な制限を課します。たとえば、8文字の基本20ユーザーコード（約34.5ビットのエントロピー）を使用する場合、レート制限の間隔と有効期間は、同じ2 ^ -32の確率を得るために5回の試行のみを許可する必要があります。ランダムな推測による成功。
A successful brute forcing of the user code would enable the attacker to approve the authorization grant with their own credentials, after which the device would receive a device authorization grant linked to the attacker's account. This is the opposite scenario to an OAuth bearer token being brute forced, whereby the attacker gains control of the victim's authorization grant. Such attacks may not always make economic sense. For example, for a video app, the device owner may then be able to purchase movies using the attacker's account (though even in this case a privacy risk would still remain and thus is important to protect against). Furthermore, some uses of the device flow give the granting account the ability to perform actions that need to be protected, such as controlling the device.
ユーザーコードのブルートフォースが成功すると、攻撃者は独自の資格情報で承認付与を承認でき、その後、デバイスは攻撃者のアカウントにリンクされたデバイス承認付与を受け取ります。これはブルートフォースされるOAuthベアラートークンとは逆のシナリオであり、攻撃者は被害者の許可付与の制御を取得します。このような攻撃は、必ずしも経済的に意味があるとは限りません。たとえば、ビデオアプリの場合、デバイスの所有者は攻撃者のアカウントを使用して映画を購入できる可能性があります（ただし、この場合でもプライバシーリスクが残るため、保護することが重要です）。さらに、デバイスフローの一部の使用は、デバイスの制御など、保護する必要があるアクションを実行する権限を付与アカウントに与えます。
The precise length of the user code and the entropy contained within is at the discretion of the authorization server, which needs to consider the sensitivity of their specific protected resources, the practicality of the code length from a usability standpoint, and any mitigations that are in place, such as rate-limiting, when determining the user code format.
ユーザーコードとその中に含まれるエントロピーの正確な長さは、承認サーバーの裁量にあります。承認サーバーは、ユーザーの特定の保護されたリソースの機密性、使いやすさの観点からのコード長の実用性、およびユーザーコードのフォーマットを決定する際のレート制限などの場所。
An attacker who guesses the device code would be able to potentially obtain the authorization code once the user completes the flow. As the device code is not displayed to the user and thus there are no usability considerations on the length, a very high entropy code SHOULD be used.
デバイスコードを推測する攻撃者は、ユーザーがフローを完了すると、認証コードを取得できる可能性があります。デバイスコードはユーザーに表示されないため、長さに関する使いやすさの考慮事項がないため、非常に高いエントロピーコードを使用する必要があります（SHOULD）。
Unlike other native application OAuth 2.0 flows, the device requesting the authorization is not the same as the device from which the user grants access. Thus, signals from the approving user's session and device are not always relevant to the trustworthiness of the client device.
他のネイティブアプリケーションのOAuth 2.0フローとは異なり、承認を要求するデバイスは、ユーザーがアクセスを許可するデバイスとは異なります。したがって、承認ユーザーのセッションとデバイスからの信号は、クライアントデバイスの信頼性に必ずしも関連しているわけではありません。
Note that if an authorization server used with this flow is malicious, then it could perform a man-in-the-middle attack on the backchannel flow to another authorization server. In this scenario, the man-in-the-middle is not completely hidden from sight, as the end user would end up on the authorization page of the wrong service, giving them an opportunity to notice that the URL in the browser's address bar is wrong. For this to be possible, the device manufacturer must either be the attacker and shipping a device intended to perform the man-in-the-middle attack, or be using an authorization server that is controlled by an attacker, possibly because the attacker compromised the authorization server used by the device. In part, the person purchasing the device is counting on the manufacturer and its business partners to be trustworthy.
このフローで使用される承認サーバーが悪意のある場合、別の承認サーバーへのバックチャネルフローに対して中間者攻撃を実行する可能性があることに注意してください。このシナリオでは、エンドユーザーがブラウザーのアドレスバーのURLが間違っていることに気づく機会を与え、エンドユーザーが誤ったサービスの承認ページに到達するため、中間者が完全に見えなくなります。違う。これを可能にするには、デバイスの製造元が攻撃者であり、man-in-the-middle攻撃を実行することを目的としたデバイスを出荷するか、または攻撃者が制御した認証サーバーを使用している必要があります。デバイスが使用する認証サーバー。一部には、デバイスを購入する人は、メーカーとそのビジネスパートナーが信頼できるものと期待しています。
It is possible for the device flow to be initiated on a device in an attacker's possession. For example, an attacker might send an email instructing the target user to visit the verification URL and enter the user code. To mitigate such an attack, it is RECOMMENDED to inform the user that they are authorizing a device during the user-interaction step (see Section 3.3) and to confirm that the device is in their possession. The authorization server SHOULD display information about the device so that the user could notice if a software client was attempting to impersonate a hardware device.
攻撃者が所有するデバイスでデバイスフローが開始される可能性があります。たとえば、攻撃者はターゲットユーザーに確認URLにアクセスしてユーザーコードを入力するように指示する電子メールを送信する可能性があります。このような攻撃を緩和するために、ユーザーとのやり取りの手順（セクション3.3を参照）中にデバイスを承認していることをユーザーに通知し、デバイスが所有していることを確認することをお勧めします。承認サーバーは、ソフトウェアクライアントがハードウェアデバイスを偽装しようとしたかどうかをユーザーが確認できるように、デバイスに関する情報を表示する必要があります（SHOULD）。
For authorization servers that support the "verification_uri_complete" optimization discussed in Section 3.3.1, it is particularly important to confirm that the device is in the user's possession, as the user no longer has to type in the code being displayed on the device manually. One suggestion is to display the code during the authorization flow and ask the user to verify that the same code is currently being displayed on the device they are setting up.
3.3.1項で説明した「verification_uri_complete」最適化をサポートする認証サーバーの場合、ユーザーがデバイスに表示されているコードを手動で入力する必要がなくなるため、デバイスがユーザーの所有物であることを確認することが特に重要です。 1つの提案は、承認フロー中にコードを表示し、セットアップしているデバイスに現在同じコードが表示されていることを確認するようにユーザーに依頼することです。
The user code needs to have a long enough lifetime to be useable (allowing the user to retrieve their secondary device, navigate to the verification URI, log in, etc.) but should be sufficiently short to limit the usability of a code obtained for phishing. This doesn't prevent a phisher from presenting a fresh token, particularly if they are interacting with the user in real time, but it does limit the viability of codes sent over email or text message.
ユーザーコードは、使用可能になるのに十分な長さである必要があります（ユーザーが自分のセカンダリデバイスを取得し、検証URIに移動し、ログインするなど）。ただし、フィッシング用に取得したコードの使いやすさを制限するには、十分に短い必要があります。 。これは、特にユーザーがリアルタイムでやり取りしている場合、フィッシャーが新しいトークンを提示することを妨げませんが、電子メールまたはテキストメッセージで送信されるコードの実行可能性を制限します。
While the device is pending authorization, it may be possible for a malicious user to physically spy on the device user interface (by viewing the screen on which it's displayed, for example) and hijack the session by completing the authorization faster than the user that initiated it. Devices SHOULD take into account the operating environment when considering how to communicate the code to the user to reduce the chances it will be observed by a malicious user.
デバイスが承認を保留している間、悪意のあるユーザーがデバイスのユーザーインターフェイスを物理的にスパイし（デバイスが表示されている画面を表示するなど）、開始したユーザーよりも早く承認を完了することでセッションを乗っ取る可能性がありますそれ。デバイスは、悪意のあるユーザーによってコードが観察される可能性を減らすためにユーザーにコードを通信する方法を検討する際に、動作環境を考慮する必要があります。
Device clients are generally incapable of maintaining the confidentiality of their credentials, as users in possession of the device can reverse-engineer it and extract the credentials. Therefore, unless additional measures are taken, they should be treated as public clients (as defined by Section 2.1 of [RFC6749]), which are susceptible to impersonation. The security considerations of Section 5.3.1 of [RFC6819] and Sections 8.5 and 8.6 of [RFC8252] apply to such clients.
デバイスを所有するユーザーはデバイスをリバースエンジニアリングして資格情報を抽出できるため、デバイスクライアントは通常、資格情報の機密性を維持できません。したがって、追加の対策を講じない限り、なりすましの影響を受けやすいパブリッククライアント（[RFC6749]のセクション2.1で定義）として扱う必要があります。このようなクライアントには、[RFC6819]のセクション5.3.1および[RFC8252]のセクション8.5および8.6のセキュリティに関する考慮事項が適用されます。
The user may also be able to obtain the "device_code" and/or other OAuth bearer tokens issued to their client, which would allow them to use their own authorization grant directly by impersonating the client. Given that the user in possession of the client credentials can already impersonate the client and create a new authorization grant (with a new "device_code"), this doesn't represent a separate impersonation vector.
ユーザーは、クライアントに発行された「device_code」やその他のOAuthベアラートークンを取得できる場合もあります。これにより、クライアントになりすまして直接自分の承認付与を使用できるようになります。クライアントの資格情報を所有しているユーザーが既にクライアントを偽装し、新しい承認付与（新しい "device_code"を使用）を作成できる場合、これは別の偽装ベクトルを表すものではありません。
There is no requirement that the user code be displayed by the device visually. Other methods of one-way communication can potentially be used, such as text-to-speech audio or Bluetooth Low Energy. To mitigate an attack in which a malicious user can bootstrap their credentials on a device not in their control, it is RECOMMENDED that any chosen communication channel only be accessible by people in close proximity, for example, users who can see or hear the device.
ユーザーコードがデバイスによって視覚的に表示される必要はありません。テキスト音声変換オーディオやBluetooth Low Energyなど、一方向通信の他の方法を使用できる可能性があります。悪意のあるユーザーが自分の制御下にないデバイスで資格情報をブートストラップできる攻撃を緩和するために、選択した通信チャネルには、デバイスを表示または聞くことができるユーザーなど、近くにいる人だけがアクセスできるようにすることをお勧めします。
This section is a non-normative discussion of usability considerations.
このセクションは、ユーザビリティに関する考慮事項の非規範的な説明です。
For many users, their nearest Internet-connected device will be their mobile phone; typically, these devices offer input methods that are more time-consuming than a computer keyboard to change the case or input numbers. To improve usability (improving entry speed and reducing retries), the limitations of such devices should be taken into account when selecting the user code character set.
多くのユーザーにとって、最も近いインターネット接続デバイスは携帯電話です。通常、これらのデバイスは、ケースを変更したり番号を入力したりするために、コンピューターのキーボードよりも時間がかかる入力方法を提供します。使いやすさを向上させる（入力速度を改善し、再試行を減らす）には、ユーザーコード文字セットを選択するときに、そのようなデバイスの制限を考慮する必要があります。
One way to improve input speed is to restrict the character set to case-insensitive A-Z characters, with no digits. These characters can typically be entered on a mobile keyboard without using modifier keys. Further removing vowels to avoid randomly creating words results in the base 20 character set "BCDFGHJKLMNPQRSTVWXZ". Dashes or other punctuation may be included for readability.
入力速度を向上させる1つの方法は、文字セットを数字のない大文字と小文字を区別しないA-Z文字に制限することです。これらの文字は通常、修飾キーを使用せずにモバイルキーボードで入力できます。ランダムに単語を作成しないように母音をさらに削除すると、ベース20の文字セット「BCDFGHJKLMNPQRSTVWXZ」になります。読みやすいようにダッシュやその他の句読点が含まれている場合があります。
An example user code following this guideline, "WDJB-MJHT", contains 8 significant characters and has dashes added for end-user readability. The resulting entropy is 20^8.
このガイドライン「WDJB-MJHT」に続くユーザーコードの例には、8つの重要な文字が含まれており、エンドユーザーが読みやすいようにダッシュが追加されています。結果のエントロピーは20 ^ 8です。
Pure numeric codes are also a good choice for usability, especially for clients targeting locales where A-Z character keyboards are not used, though the length of such a code needs to be longer to maintain high entropy.
高エントロピーを維持するためにこのようなコードの長さを長くする必要がありますが、純粋な数値コードは、特にA-Z文字キーボードが使用されていないロケールをターゲットとするクライアントにとって、使い勝手にとっても良い選択です。
An example numeric user code that contains 9 significant digits and dashes added for end-user readability with an entropy of 10^9 is "019-450-730".
エントロピーが10 ^ 9のエンドユーザーの読みやすさのために追加された9桁の有効数字とダッシュを含む数値ユーザーコードの例は、「019-450-730」です。
When processing the inputted user code, the server should strip dashes and other punctuation that it added for readability (making the inclusion of such punctuation by the user optional). For codes using only characters in the A-Z range, as with the base 20 charset defined above, the user's input should be uppercased before a comparison to account for the fact that the user may input the equivalent lowercase characters. Further stripping of all characters outside the chosen character set is recommended to reduce instances where an errantly typed character (like a space character) invalidates otherwise valid input.
入力されたユーザーコードを処理するとき、サーバーはダッシュとその他の句読点を削除して読みやすくします（ユーザーによるそのような句読点の追加はオプションです）。上記で定義された基本20文字セットと同様に、AからZの範囲の文字のみを使用するコードの場合、ユーザーが同等の小文字を入力できるという事実を考慮して、比較の前にユーザーの入力を大文字にする必要があります。誤って入力された文字（スペース文字など）が有効な入力を無効にするインスタンスを減らすために、選択した文字セット以外のすべての文字をさらに取り除くことをお勧めします。
It is RECOMMENDED to avoid character sets that contain two or more characters that can easily be confused with each other, like "0" and "O" or "1", "l" and "I". Furthermore, to the extent practical, when a character set contains a character that may be confused with characters outside the character set, a character outside the set MAY be substituted with the one in the character set with which it is commonly confused; for example, "O" may be substituted for "0" when using the numerical 0-9 character set.
「0」と「O」または「1」、「l」と「I」のように、互いに混同されやすい2つ以上の文字を含む文字セットを避けることをお勧めします。さらに、実用的な範囲で、文字セットに文字セット外の文字と混同される可能性のある文字が含まれている場合、セット外の文字は、一般的に混同されている文字セット内の文字で置き換えてもよい（MAY）。たとえば、数値0〜9の文字セットを使用する場合、「O」を「0」の代わりに使用できます。
Devices and authorization servers MAY negotiate an alternative code transmission and user-interaction method in addition to the one described in Section 3.3. Such an alternative user-interaction flow could obviate the need for a browser and manual input of the code, for example, by using Bluetooth to transmit the code to the authorization server's companion app. Such interaction methods can utilize this protocol as, ultimately, the user just needs to identify the authorization session to the authorization server; however, user interaction other than through the verification URI is outside the scope of this specification.
デバイスと認証サーバーは、セクション3.3で説明されているものに加えて、代替のコード送信とユーザー対話の方法をネゴシエートする場合があります。このような代替のユーザーインタラクションフローにより、たとえばBluetoothを使用してコードを承認サーバーのコンパニオンアプリに送信することにより、ブラウザーやコードの手動入力の必要性をなくすことができます。最終的に、ユーザーは認証サーバーへの認証セッションを識別する必要があるだけなので、このような対話方法はこのプロトコルを利用できます。ただし、検証URIを介した以外のユーザー操作は、この仕様の範囲外です。
This specification registers the following values in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749].
この仕様は、[RFC6749]によって確立されたIANA "OAuth Parameters"レジストリ[IANA.OAuth.Parameters]に以下の値を登録します。
Name: device_code Parameter Usage Location: token request Change Controller: IESG Reference: Section 3.4 of RFC 8628
名前：device_codeパラメータ使用場所：トークンリクエスト変更コントローラ：IESGリファレンス：RFC 8628のセクション3.4
This specification registers the following values in the IANA "OAuth URI" registry [IANA.OAuth.Parameters] established by [RFC6755].
この仕様は、[RFC6755]によって確立されたIANA "OAuth URI"レジストリ[IANA.OAuth.Parameters]に以下の値を登録します。
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
This specification registers the following values in the IANA "OAuth Extensions Error Registry" registry [IANA.OAuth.Parameters] established by [RFC6749].
この仕様は、[RFC6749]によって確立されたIANA "OAuth Extensions Error Registry"レジストリ[IANA.OAuth.Parameters]に以下の値を登録します。
Name: authorization_pending Usage Location: Token endpoint response Protocol Extension: RFC 8628 Change Controller: IETF Reference: Section 3.5 of RFC 8628
名前：authorization_pending使用場所：トークンエンドポイントレスポンスプロトコル拡張：RFC 8628変更コントローラー：IETFリファレンス：RFC 8628のセクション3.5
Name: access_denied Usage Location: Token endpoint response Protocol Extension: RFC 8628 Change Controller: IETF Reference: Section 3.5 of RFC 8628
名前：access_denied使用場所：トークンエンドポイントレスポンスプロトコル拡張：RFC 8628変更コントローラー：IETFリファレンス：RFC 8628のセクション3.5
Name: slow_down Usage Location: Token endpoint response Protocol Extension: RFC 8628 Change Controller: IETF Reference: Section 3.5 of RFC 8628
名前：slow_down使用場所：トークンエンドポイントレスポンスプロトコル拡張：RFC 8628変更コントローラー：IETFリファレンス：RFC 8628のセクション3.5
Name: expired_token Usage Location: Token endpoint response Protocol Extension: RFC 8628 Change Controller: IETF Reference: Section 3.5 of RFC 8628
名前：expired_token使用場所：トークンエンドポイントレスポンスプロトコル拡張：RFC 8628変更コントローラー：IETFリファレンス：RFC 8628のセクション3.5
This specification registers the following values in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414].
この仕様は、[RFC8414]によって確立されたIANA "OAuth Authorization Server Metadata"レジストリ[IANA.OAuth.Parameters]に以下の値を登録します。
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
メタデータ名：device_authorization_endpointメタデータの説明：承認サーバーのデバイス承認エンドポイントのURL変更コントローラー：IESGリファレンス：RFC 8628のセクション4
[IANA.OAuth.Parameters] IANA, "OAuth Parameters", <http://www.iana.org/assignments/oauth-parameters>.
[IANA.OAuth.Parameters] IANA、「OAuthパラメータ」、<http://www.iana.org/assignments/oauth-parameters>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https://www.rfc-editor.org/info/rfc6749>。
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <https://www.rfc-editor.org/info/rfc6755>.
[RFC6755] Campbell、B。およびH. Tschofenig、「An an ITF URN Sub-Namespace for OAuth」、RFC 6755、DOI 10.17487 / RFC6755、2012年10月、<https://www.rfc-editor.org/info/rfc6755 >。
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <https://www.rfc-editor.org/info/rfc6819>.
[RFC6819] Lodderstedt、T.、Ed。、McGloin、M。、およびP. Hunt、「OAuth 2.0脅威モデルとセキュリティの考慮事項」、RFC 6819、DOI 10.17487 / RFC6819、2013年1月、<https：//www.rfc -editor.org/info/rfc6819>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, <https://www.rfc-editor.org/info/rfc8252>.
[RFC8252]デニス、W、およびJブラッドリー、「ネイティブアプリのOAuth 2.0」、BCP 212、RFC 8252、DOI 10.17487 / RFC8252、2017年10月、<https://www.rfc-editor.org/info/rfc8252 >。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/info/rfc8414>.
[RFC8414] Jones、M.、Sakimura、N.、J。Bradley、「OAuth 2.0 Authorization Server Metadata」、RFC 8414、DOI 10.17487 / RFC8414、2018年6月、<https://www.rfc-editor.org/ info / rfc8414>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
Acknowledgements
謝辞
The starting point for this document was the Internet-Draft draft-recordon-oauth-v2-device, authored by David Recordon and Brent Goldman, which itself was based on content in draft versions of the OAuth 2.0 protocol specification removed prior to publication due to a then-lack of sufficient deployment expertise. Thank you to the OAuth Working Group members who contributed to those earlier drafts.
このドキュメントの出発点は、David RecordonとBrent Goldmanによって作成されたInternet-Draft draft-recordon-oauth-v2-deviceでした。これは、公開前に削除されたOAuth 2.0プロトコル仕様のドラフトバージョンのコンテンツに基づいていました。当時は、十分な導入の専門知識が不足しています。以前のドラフトに貢献してくれたOAuthワーキンググループのメンバーに感謝します。
This document was produced in the OAuth Working Group under the chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig, with Benjamin Kaduk, Kathleen Moriarty, and Eric Rescorla serving as Security Area Directors.
このドキュメントは、Rifaat Shekh-YusefとHannes Tschofenigの議長の下でOAuthワーキンググループで作成され、Benjamin Kaduk、Kathleen Moriarty、およびEric Rescorlaがセキュリティエリアディレクターを務めています。
The following individuals contributed ideas, feedback, and wording that shaped and formed the final specification:
以下の個人が、最終的な仕様を形成および形成するアイデア、フィードバック、および表現を提供しました。
Ben Campbell, Brian Campbell, Roshni Chandrashekhar, Alissa Cooper, Eric Fazendin, Benjamin Kaduk, Jamshid Khosravian, Mirja Kuehlewind, Torsten Lodderstedt, James Manger, Dan McNulty, Breno de Medeiros, Alexey Melnikov, Simon Moffatt, Stein Myrseth, Emond Papegaaij, Justin Richer, Adam Roach, Nat Sakimura, Andrew Sciberras, Marius Scurtescu, Filip Skokan, Robert Sparks, Ken Wang, Christopher Wood, Steven E. Wright, and Qin Wu.
ベンキャンベル、ブライアンキャンベル、ロシュニチャンドラシェカール、アリッサクーパー、エリックファゼンディン、ベンジャミンカドゥック、ジャムシッドコスラビアン、ミルジャキュールウィンド、トルステンロダーシュテット、ジェームズマンガー、ダンマクナルティ、ブレノデメデイロス、アレクセイメルニコフ、サイモンモファット、スタインミルペスエシュマンRicher、Adam Roach、Nat Sakimura、Andrew Sciberras、Marius Scurtescu、Filip Skokan、Robert Sparks、Ken Wang、Christopher Wood、Steven E. Wright、Qin Wu。
Authors' Addresses
著者のアドレス
William Denniss Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 United States of America
William Denniss Google 1600 Amphitheatre Pkwy Mountain View、CA 94043アメリカ合衆国
Email: wdenniss@google.com
URI: https://wdenniss.com/deviceflow
John Bradley Ping Identity
ジョンブラッドリーピンアイデンティティ
Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Michael B. Jones Microsoft
マイケルB.ジョーンズマイクロソフト
Email: mbj@microsoft.com
URI: http://self-issued.info/
Hannes Tschofenig ARM Limited Austria
Hannes Tschofenig ARM Limitedオーストリア
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at