1.1. Notational Conventions

1.1. 表記上の規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

キーワード「しなければなりません（MUST）」、「してはなりません（MUST NOT）」、 「要求されています（REQUIRED）」、 「することになります（SHALL）」、「することはありません（SHALL NOT）」、 「すべきです（SHOULD）」、「すべきではありません（SHOULD NOT）」、 「推奨されます（RECOMMENDED）」、「推奨されません（NOT RECOMMENDED）」、 「してもよいです（MAY）」、「選択できます（OPTIONAL）」は、 [RFC2119]に記載されているとおりに解釈されるものとします。

This document uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the following rules are included from HTTP/1.1 [RFC2617]: auth-param and auth-scheme; and from "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986]: URI-reference.

このドキュメントでは、[RFC5234]の拡張バッカス・ナウア形式（ABNF）表記法を使用しています。さらに、以下の規則が含まれています。 HTTP/1.1 [RFC2617]: auth-paramおよびauth-scheme。「Uniform Resource Identifier（URI）：Generic Syntax」[RFC3986]：URI-reference。

Unless otherwise noted, all the protocol parameter names and values are case sensitive.

とくに注記がない限り、すべてのプロトコルパラメーター名および値は大文字と小文字を区別します。

1.2. Terminology

1.2. 用語

Bearer Token A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).

Bearer token セキュリティートークンで、保持している当事者（「Bearer」）がトークンを使用できるという特性を持ちます。Bearerトークンを使用する場合、Bearerは暗号鍵の所有を証明する必要はありません（所有の証明）。

All other terms are as defined in "The OAuth 2.0 Authorization Framework" [RFC6749].

その他の用語は、『OAuth 2.0 Authorization Framework』[RFC6749]で定義されているものと同じ意味で使用されます。

1.3. Overview

1.3. 概要

OAuth provides a method for clients to access a protected resource on behalf of a resource owner. In the general case, before a client can access a protected resource, it must first obtain an authorization grant from the resource owner and then exchange the authorization grant for an access token. The access token represents the grant's scope, duration, and other attributes granted by the authorization grant. The client accesses the protected resource by presenting the access token to the resource server. In some cases, a client can directly present its own credentials to an authorization server to obtain an access token without having to first obtain an authorization grant from a resource owner.

OAuthは、クライアントがリソースオーナーの代理で保護されたリソースにアクセスするための方法を提供します。一般的な場合では、クライアントが保護されたリソースにアクセスする前に、まずリソースオーナーから承認許可を取得し、その承認許可をアクセストークンに交換する必要があります。アクセストークンは、承認許可によって付与されたスコープ、期間、およびその他の属性を表します。クライアントは、アクセストークンをリソースサーバーに提示することで保護されたリソースにアクセスします。一部の場合では、クライアントは、リソースオーナーから承認許可を取得することなく、直接認証サーバーに自分自身の資格情報を提示してアクセストークンを取得することができます。

The access token provides an abstraction, replacing different authorization constructs (e.g., username and password, assertion) for a single token understood by the resource server. This abstraction enables issuing access tokens valid for a short time period, as well as removing the resource server's need to understand a wide range of authentication schemes.

アクセストークンは、リソースサーバーが理解できる単一のトークンに置き換えることで、異なる認証構造（例：ユーザー名とパスワード、アサーション）を抽象化します。この抽象化により、短時間有効なアクセストークンを発行することができ、リソースサーバーが理解する必要がある認証スキームの範囲を広げる必要がなくなります。

The abstract OAuth 2.0 flow illustrated in Figure 1 describes the interaction between the client, resource owner, authorization server, and resource server (described in [RFC6749]). The following two steps are specified within this document:

図1に示す抽象的なOAuth 2.0フローは、クライアント、リソースオーナー、認可サーバー、およびリソースサーバー（[RFC6749]で説明されている）の間の相互作用を説明しています。このドキュメントでは、次の2つのステップが指定されています。

(E) The client requests the protected resource from the resource server and authenticates by presenting the access token.

(E) クライアントは、アクセストークンを提示して認証し、リソースサーバーから保護されたリソースを要求します。

(F) The resource server validates the access token, and if valid, serves the request.

(F) リソースサーバーはアクセストークンを検証し、有効であればリクエストを処理します。

This document also imposes semantic requirements upon the access token returned in step (D).

このドキュメントは、ステップ(D)で返されるアクセストークンに対して意味的な要件を課します。

2.1. Authorization Request Header Field

2.1. Authorizationリクエストヘッダーフィールド

When sending the access token in the "Authorization" request header field defined by HTTP/1.1 [RFC2617], the client uses the "Bearer" authentication scheme to transmit the access token.

HTTP/1.1 [RFC2617]で定義された「Authorization」リクエストヘッダーフィールドにアクセストークンを送信する場合、クライアントは「Bearer」認証スキームを使用してアクセストークンを送信します。

For example:

例:

The syntax of the "Authorization" header field for this scheme follows the usage of the Basic scheme defined in Section 2 of [RFC2617]. Note that, as with Basic, it does not conform to the generic syntax defined in Section 1.2 of [RFC2617] but is compatible with the general authentication framework being developed for HTTP 1.1 [HTTP-AUTH], although it does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows:

このスキームの「Authorization」ヘッダーフィールドの構文は、[RFC2617]のSection 2で定義されたBasicスキームの使用方法にしたがいます。Basicと同様に、[RFC2617]のSection 1.2で定義された一般的な構文には準拠していませんが、HTTP 1.1で開発されている一般的な認証フレームワークには互換性があります。ただし、既存の展開を反映するために、そこで概説されている推奨される方法にはしたがいません。Bearer資格情報の構文は次のとおりです。

Clients SHOULD make authenticated requests with a bearer token using the "Authorization" request header field with the "Bearer" HTTP authorization scheme. Resource servers MUST support this method.

クライアントは、Bearerトークンを使用して認証されたリクエストを「Authorization」リクエストヘッダーフィールドを使用して送信すべきです（SHOULD）（HTTP認証スキーム「Bearer」を使用）。リソースサーバーは、この方法をサポートしなければなりません（MUST）。

2.2. Form-Encoded Body Parameter

2.2. Form-Encoded Body Parameter

When sending the access token in the HTTP request entity-body, the client adds the access token to the request-body using the "access_token" parameter. The client MUST NOT use this method unless all of the following conditions are met:

アクセストークンをHTTPリクエストエンティティボディに送信する場合、クライアントは「access_token」パラメーターを使用してリクエストボディにアクセストークンを追加します。以下の条件がすべて満たされている場合、クライアントはこの方法を使用してはなりません。

• The HTTP request entity-header includes the "Content-Type" header field set to "application/x-www-form-urlencoded".

• HTTPリクエストエンティティヘッダーに「Content-Type」ヘッダーフィールドが含まれ、値が「application/x-www-form-urlencoded」に設定されていること。

• The entity-body follows the encoding requirements of the "application/x-www-form-urlencoded" content-type as defined by HTML 4.01 [W3C.REC-html401-19991224].

• エンティティボディが、HTML 4.01 [W3C.REC-html401-19991224]で定義されている「application/x-www-form-urlencoded」コンテンツタイプのエンコーディング要件に従っていること。

• The HTTP request entity-body is single-part.

• HTTPリクエストエンティティボディが単一パートであること。

• The content to be encoded in the entity-body MUST consist entirely of ASCII [USASCII] characters.

• エンティティボディにエンコードされるコンテンツは、ASCII [USASCII]文字のみで構成されていること。

• The HTTP request method is one for which the request-body has defined semantics. In particular, this means that the "GET" method MUST NOT be used.

• HTTPリクエストメソッドが、リクエストボディに定義されたセマンティクスを持つものであること。とくに、「GET」メソッドは使用できません。

The entity-body MAY include other request-specific parameters, in which case the "access_token" parameter MUST be properly separated from the request-specific parameters using "&" character(s) (ASCII code 38).

エンティティボディには、リクエスト固有のパラメーターを含めることができますが、その場合、「access_token」パラメーターは「&」文字（ASCIIコード38）を使用してリクエスト固有のパラメーターから適切に分離する必要があります。

For example, the client makes the following HTTP request using transport-layer security:

たとえば、クライアントはトランスポート層セキュリティーを使用して、以下のHTTPリクエストを行います。

The "application/x-www-form-urlencoded" method SHOULD NOT be used except in application contexts where participating browsers do not have access to the "Authorization" request header field. Resource servers MAY support this method.

「application/x-www-form-urlencoded」メソッドは、参加するブラウザが「Authorization」リクエストヘッダーフィールドにアクセスできないアプリケーションコンテキスト以外では、使用すべきではありません（SHOULD NOT）。リソースサーバーは、このメソッドをサポートしてもよいです（MAY）。

2.3. URI Query Parameter

2.3. URIクエリパラメーター

When sending the access token in the HTTP request URI, the client adds the access token to the request URI query component as defined by "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986], using the "access_token" parameter.

アクセストークンをHTTPリクエストURIで送信する場合、クライアントは、「Uniform Resource Identifier (URI): Generic Syntax」[RFC3986]で定義されたリクエストURIクエリコンポーネントに「access_token」パラメーターを使用してアクセストークンを追加します。

For example, the client makes the following HTTP request using transport-layer security:

たとえば、クライアントは、トランスポート層セキュリティーを使用して、以下のHTTPリクエストを行います。

The HTTP request URI query can include other request-specific parameters, in which case the "access_token" parameter MUST be properly separated from the request-specific parameters using "&" character(s) (ASCII code 38).

HTTPリクエストURIクエリには、他のリクエスト固有のパラメーターを含めることができます。この場合、「access_token」パラメーターは、リクエスト固有のパラメーターと適切に区別するために、「&」文字（ASCIIコード38）を使用して分離しなければなりません（MUST）。

For example:

例:

https://server.example.com/resource?access_token=mF_9.B5f-4.1JqM&p=q

https://server.example.com/resource?access_token=mF_9.B5f-4.1JqM&p=q

Clients using the URI Query Parameter method SHOULD also send a Cache-Control header containing the "no-store" option. Server success (2XX status) responses to these requests SHOULD contain a Cache-Control header with the "private" option.

URIクエリパラメーターメソッドを使用するクライアントは、「no-store」オプションを含むCache-Controlヘッダーを送信すべきです（SHOULD）。これらのリクエストに対するサーバーの成功（2XXステータス）レスポンスは、「private」オプションを含むCache-Controlヘッダーを含むべきです（SHOULD）。

Because of the security weaknesses associated with the URI method (see Section 5), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body. Resource servers MAY support this method.

URIメソッドに関連するセキュリティー上の脆弱性（セクション5を参照）により、アクセストークンを含むURLがログに記録される可能性が高いため、アクセストークンを「Authorization」リクエストヘッダーフィールドまたはHTTPリクエストエンティティボディに輸送することが不可能な場合を除き、このメソッドは使用すべきではありません（SHOULD NOT）。リソースサーバーは、このメソッドをサポートしてもよいです（MAY）。

This method is included to document current use; its use is not recommended, due to its security deficiencies (see Section 5) and also because it uses a reserved query parameter name, which is counter to URI namespace best practices, per "Architecture of the World Wide Web, Volume One" [W3C.REC-webarch-20041215].

このメソッドは、現在の使用状況を文書化するために含まれていますが、その使用は推奨されていません。これは、そのセキュリティー上の欠陥（セクション5を参照）と、URI名前空間のベストプラクティスに反する予約済みのクエリパラメーター名を使用するためです。「World Wide Webのアーキテクチャ、第1巻」[W3C.REC-webarch-20041215]によると、URI名前空間のベストプラクティスに反するためです。

3.1. Error Codes

3.1. エラーコード

When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and includes one of the following error codes in the response:

リクエストが失敗した場合、リソースサーバーは適切なHTTPステータスコード（通常は400、401、403、または405）を使用して応答し、応答に次のエラーコードのいずれかを含めます。

invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code.

invalid_request リクエストに必要なパラメーターが欠落している、サポートされていないパラメーターまたはパラメーター値が含まれている、同じパラメーターが繰り返されている、アクセストークンを含めるために複数の方法を使用している、またはその他の形式で不正である場合。リソースサーバーはHTTP 400（不正なリクエスト）ステータスコードで応答すべきです（SHOULD）。

invalid_token The access token provided is expired, revoked, malformed, or invalid for other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request.

invalid_token 提供されたアクセストークンが期限切れ、取り消され、形式が不正であるか、その他の理由で無効である場合、リソースはHTTP 401（認証失敗）ステータスコードで応答すべきです（SHOULD）。クライアントは新しいアクセストークンを要求して保護されたリソースリクエストを再試行してもよいです（MAY）。

insufficient_scope The request requires higher privileges than provided by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the "scope" attribute with the scope necessary to access the protected resource.

insufficient_scope リクエストに必要な権限がアクセストークンで提供される権限よりも高い場合、リソースサーバーはHTTP 403（禁止）ステータスコードで応答すべきです（SHOULD）。また、リソースへのアクセスに必要なスコープを含む「scope」属性を含めてもよいです（MAY）。

If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT include an error code or other error information.

リクエストに認証情報が含まれていない場合（たとえば、クライアントが認証が必要であることを知らず、またはサポートされていない認証方法を使用して試行した場合）、リソースサーバーはエラーコードやその他のエラー情報を含めるべきではありません（SHOULD NOT）。

For example:

例:

5.1. Security Threats

5.1. セキュリティー脅威

The following list presents several common threats against protocols utilizing some form of tokens. This list of threats is based on NIST Special Publication 800-63 [NIST800-63]. Since this document builds on the OAuth 2.0 Authorization specification [RFC6749], we exclude a discussion of threats that are described there or in related documents.

以下のリストは、トークンを使用するプロトコルに対するいくつかの一般的な脅威を示しています。この脅威のリストは、NIST特別出版物800-63 [NIST800-63]に基づいています。このドキュメントはOAuth 2.0認可仕様 [RFC6749]にもとづいているため、そこで説明されている脅威や関連するドキュメントで説明されている脅威については除外します。

Token manufacture/modification: An attacker may generate a bogus token or modify the token contents (such as the authentication or attribute statements) of an existing token, causing the resource server to grant inappropriate access to the client. For example, an attacker may modify the token to extend the validity period; a malicious client may modify the assertion to gain access to information that they should not be able to view.

トークンの生成/変更：攻撃者は、偽のトークンを生成したり、既存のトークンの認証ステートメントや属性ステートメントなどのトークンの内容を変更することで、リソースサーバーがクライアントに不適切なアクセスを許可することができます。たとえば、攻撃者はトークンを変更して有効期間を延長することができます。悪意のあるクライアントは、アサーションを変更して、閲覧することができない情報にアクセスすることができます。

Token disclosure: Tokens may contain authentication and attribute statements that include sensitive information.

トークンの開示：トークンには、機密情報を含む認証および属性ステートメントが含まれる場合があります。

Token redirect: An attacker uses a token generated for consumption by one resource server to gain access to a different resource server that mistakenly believes the token to be for it.

トークンリダイレクト：攻撃者は、誤ってトークンが自分のものであると信じている別のリソースサーバーにアクセスするために生成されたトークンを使用します。

Token replay: An attacker attempts to use a token that has already been used with that resource server in the past.

トークンの再利用：攻撃者は、過去にそのリソースサーバーで使用されたトークンを再利用しようとします。

5.2. Threat Mitigation

5.2. Threat Mitigation

A large range of threats can be mitigated by protecting the contents of the token by using a digital signature or a Message Authentication Code (MAC). Alternatively, a bearer token can contain a reference to authorization information, rather than encoding the information directly. Such references MUST be infeasible for an attacker to guess; using a reference may require an extra interaction between a server and the token issuer to resolve the reference to the authorization information. The mechanics of such an interaction are not defined by this specification.

デジタル署名またはメッセージ認証コード（MAC）を使用してトークンの内容を保護することにより、さまざまな脅威を軽減できます。また、ベアラートークンには、情報を直接エンコードする代わりに、認証情報への参照が含まれる場合があります。そのような参照は、攻撃者が推測することが不可能である必要があります。参照を使用する場合、サーバーとトークン発行者の間に追加のやり取りが必要になる場合があります。この仕様では、そのようなやり取りのメカニズムは定義されていません。MUST

This document does not specify the encoding or the contents of the token; hence, detailed recommendations about the means of guaranteeing token integrity protection are outside the scope of this document. The token integrity protection MUST be sufficient to prevent the token from being modified.

このドキュメントでは、トークンのエンコード方法や内容については指定されていないため、トークンの整合性保護を保証する手段に関する詳細な推奨事項は、このドキュメントの範囲外です。トークンの整合性保護は、トークンが変更されないようにするために十分である必要があります。MUST

To deal with token redirect, it is important for the authorization server to include the identity of the intended recipients (the audience), typically a single resource server (or a list of resource servers), in the token. Restricting the use of the token to a specific scope is also RECOMMENDED.

トークンのリダイレクトに対処するためには、認証サーバーがトークンに意図された受信者（オーディエンス）のID、通常は単一のリソースサーバー（またはリソースサーバーのリスト）を含めることが重要です。トークンの使用を特定のスコープに制限することもRECOMMENDEDされます。

The authorization server MUST implement TLS. Which version(s) ought to be implemented will vary over time and will depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but it has very limited actual deployment and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246] is the most widely deployed version and will give the broadest interoperability.

認証サーバーはTLSを実装するMUSTがあります。実装すべきバージョンは時間とともに変化し、実装時の広範な展開と既知のセキュリティー脆弱性に依存します。この執筆時点では、TLSバージョン1.2が最新バージョンですが、実際の展開は非常に限定的であり、実装ツールキットで容易に利用できない場合があります。TLSバージョン1.0は最も広く展開されており、最も広範な相互運用性を提供します。[RFC5246][RFC2246]

To protect against token disclosure, confidentiality protection MUST be applied using TLS [RFC5246] with a ciphersuite that provides confidentiality and integrity protection. This requires that the communication interaction between the client and the authorization server, as well as the interaction between the client and the resource server, utilize confidentiality and integrity protection. Since TLS is mandatory to implement and to use with this specification, it is the preferred approach for preventing token disclosure via the communication channel. For those cases where the client is prevented from observing the contents of the token, token encryption MUST be applied in addition to the usage of TLS protection. As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources, including checking the Certificate Revocation List (CRL) [RFC5280].

トークンの漏洩を防ぐために、機密性保護はTLS[RFC5246]を使用して適用するMUSTされます。これには、クライアントと認証サーバーの間の通信インタラクション、およびクライアントとリソースサーバーの間のインタラクションが、機密性と整合性の保護を提供する暗号スイートを使用する必要があります。TLSは、この仕様で実装および使用する必要があるため、通信チャネルを介したトークンの漏洩を防止するための優先的なアプローチです。トークンの内容を観察できないようにする場合、トークンの暗号化MUSTがTLS保護の使用に加えて適用されます。トークンの漏洩に対するさらなる防御策として、クライアントMUSTは、保護されたリソースに対するリクエストを行うときにTLS証明書チェーンを検証する必要があります。これには、証明書失効リスト（CRL）[RFC5280]のチェックも含まれます。

Cookies are typically transmitted in the clear. Thus, any information contained in them is at risk of disclosure. Therefore, bearer tokens MUST NOT be stored in cookies that can be sent in the clear. See "HTTP State Management Mechanism" [RFC6265] for security considerations about cookies.

Cookieは通常、平文で送信されます。したがって、それらに含まれる情報は漏洩の危険にさらされます。したがって、ベアラートークンMUST NOTは、平文で送信されるCookieに保存されるべきではありません。Cookieに関するセキュリティーについては、「HTTP State Management Mechanism」[RFC6265]を参照してください。

In some deployments, including those utilizing load balancers, the TLS connection to the resource server terminates prior to the actual server that provides the resource. This could leave the token unprotected between the front-end server where the TLS connection terminates and the back-end server that provides the resource. In such deployments, sufficient measures MUST be employed to ensure confidentiality of the token between the front-end and back-end servers; encryption of the token is one such possible measure.

ロードバランサーを利用するなど、一部の展開では、リソースサーバーへのTLS接続が実際のリソースを提供するサーバーの前に終了する場合があります。これにより、フロントエンドサーバーとバックエンドサーバーの間でトークンが保護されない可能性があります。そのような展開では、トークンの機密性を確保するために、十分な措置MUSTが講じられる必要があります。トークンの暗号化は、そのような可能性がある措置の1つです。

To deal with token capture and replay, the following recommendations are made: First, the lifetime of the token MUST be limited; one means of achieving this is by putting a validity time field inside the protected part of the token. Note that using short-lived (one hour or less) tokens reduces the impact of them being leaked. Second, confidentiality protection of the exchanges between the client and the authorization server and between the client and the resource server MUST be applied. As a consequence, no eavesdropper along the communication path is able to observe the token exchange. Consequently, such an on-path adversary cannot replay the token. Furthermore, when presenting the token to a resource server, the client MUST verify the identity of that resource server, as per Section 3.1 of "HTTP Over TLS" [RFC2818]. Note that the client MUST validate the TLS certificate chain when making these requests to protected resources. Presenting the token to an unauthenticated and unauthorized resource server or failing to validate the certificate chain will allow adversaries to steal the token and gain unauthorized access to protected resources.

トークンのキャプチャと再生に対処するために、以下の推奨事項があります。まず、トークンの有効期間MUSTが制限される必要があります。これを実現する1つの手段は、トークンの保護された部分に有効期間フィールドを配置することです。短時間（1時間以下）のトークンを使用することで、漏洩の影響を軽減できます。第二に、クライアントと認証サーバー、およびクライアントとリソースサーバーの間の交換の機密性保護MUSTが適用される必要があります。その結果、通信パスにいる盗聴者はトークン交換を観察できません。したがって、そのようなパス上の攻撃者はトークンを再生できません。さらに、トークンをリソースサーバーに提示する際に、クライアントMUSTは、HTTP Over TLSのセクション3.1に従って、そのリソースサーバーのIDを検証する必要があります。証明書チェーンの検証を行わずにトークンを認証されていないリソースサーバーに提示すると、攻撃者はトークンを盗み、保護されたリソースに不正アクセスできるようになります。

5.3. Summary of Recommendations

5.3. 推奨事項の概要

Safeguard bearer tokens: Client implementations MUST ensure that bearer tokens are not leaked to unintended parties, as they will be able to use them to gain access to protected resources. This is the primary security consideration when using bearer tokens and underlies all the more specific recommendations that follow.

Bearerトークンを保護する：クライアント実装は必ず、Bearerトークンが意図しないパーティに漏洩しないようにしなければなりません（MUST）。そうしないと、彼らはそれらを使用して保護されたリソースにアクセスできるため、これはベアラトークンを使用する際の主要なセキュリティー上の考慮事項であり、以下に続くより具体的な推奨事項の基礎となります。

Validate TLS certificate chains: The client MUST validate the TLS certificate chain when making requests to protected resources. Failing to do so may enable DNS hijacking attacks to steal the token and gain unintended access.

TLS証明書チェーンの検証：クライアントは、保護されたリソースに対するリクエストを行う際にTLS証明書チェーンを検証しなければなりません（MUST）。そうしないと、DNSハイジャック攻撃によりトークンが盗まれ、意図しないアクセスが可能になる可能性があります。

Always use TLS (https): Clients MUST always use TLS [RFC5246] (https) or equivalent transport security when making requests with bearer tokens. Failing to do so exposes the token to numerous attacks that could give attackers unintended access.

常にTLS（https）を使用する：クライアントは必ず、Bearerトークンを使用してリクエストを行う場合には、常にTLS[RFC5246]（https）または同等のトランスポートセキュリティーを使用する必要があります。そうしないと、トークンが多数の攻撃にさらされ、攻撃者が意図しないアクセスを取得する可能性があります。

Don't store bearer tokens in cookies: Implementations MUST NOT store bearer tokens within cookies that can be sent in the clear (which is the default transmission mode for cookies). Implementations that do store bearer tokens in cookies MUST take precautions against cross-site request forgery.

Bearerトークンをクッキーに保存しないでください：実装は、クッキーで送信されることがデフォルトの転送モードであるため、平文で送信される可能性があるクッキー内にBearerトークンを保存してはなりません（MUST NOT）。Bearerトークンをクッキーに保存する実装は、クロスサイトリクエストフォージェリに対する予防措置を必ず講じる必要があります（MUST）。

Issue short-lived bearer tokens: Token servers SHOULD issue short-lived (one hour or less) bearer tokens, particularly when issuing tokens to clients that run within a web browser or other environments where information leakage may occur. Using short-lived bearer tokens can reduce the impact of them being leaked.

短命なBearerトークンを発行する：トークンサーバーは、とくにWebブラウザ内または情報漏洩が発生する他の環境で実行されるクライアントにトークンを発行する場合、短命（1時間以下）のBearerトークンを発行すべきです（SHOULD）。短命なBearerトークンを使用することで、漏洩の影響を軽減できます。

Issue scoped bearer tokens: Token servers SHOULD issue bearer tokens that contain an audience restriction, scoping their use to the intended relying party or set of relying parties.

発行対象のスコープ付きBearerトークン：トークンサーバーは、意図した信頼するパーティまたは信頼するパーティのセットに使用を限定するオーディエンス制限を含むBearerトークンを発行すべきです（SHOULD）。

Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be passed in page URLs (for example, as query string parameters). Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.

ページURLにBearerトークンを渡さないでください：Bearerトークンは、ページURL（たとえば、クエリ文字列パラメーターとして）に渡すべきではありません（SHOULD NOT）。代わりに、機密性対策が講じられたHTTPメッセージヘッダーまたはメッセージボディにBearerトークンを渡すべきです（SHOULD）。ブラウザ、Webサーバー、その他のソフトウェアは、ブラウザの履歴、Webサーバーのログ、およびその他のデータ構造を十分に保護できない場合があります。BearerトークンがページURLに渡される場合、攻撃者は履歴データ、ログ、またはその他の保護されていない場所からそれらを盗むことができる可能性があります。

6.1. OAuth Access Token Type Registration

6.1. OAuthアクセストークンタイプの登録

This specification registers the following access token type in the OAuth Access Token Types registry defined in [RFC6749].

この仕様書は、[RFC6749]で定義されたOAuth Access Token Typesレジストリに以下のアクセストークンタイプを登録します。

6.2. OAuth Extensions Error Registration

6.2. OAuth拡張エラーの登録

This specification registers the following error values in the OAuth Extensions Error registry defined in [RFC6749].

この仕様書は、[RFC6749]で定義されたOAuth拡張エラーレジストリに以下のエラー値を登録します。