[要約] RFC 7662は、OAuth 2.0 Token Introspectionの標準を定める文書で、OAuth 2.0トークンの現在の状態やメタデータを調べるためのプロトコルを規定しています。このプロトコルは、リソースサーバーがアクセストークンの有効性や関連する権限を認証サーバーに問い合わせる際に使用されます。この仕様は、OAuth 2.0フレームワーク内でのセキュリティとトークン管理の柔軟性を高めることを目的としています。関連するRFCには、OAuth 2.0を定義するRFC 6749やトークンリフレッシュに関するRFC 6749のセクション6などがあります。
Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 7662 October 2015
Category: Standards Track
ISSN: 2070-1721
OAuth 2.0 Token Introspection
OAuth 2.0トークンのイントロスペクション
Abstract
概要
This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.
この仕様は、保護されたリソースがOAuth 2.0承認サーバーにクエリを実行してOAuth 2.0トークンのアクティブな状態を判断し、このトークンに関するメタ情報を判断する方法を定義しています。 OAuth 2.0デプロイメントはこのメソッドを使用して、トークンの認証コンテキストに関する情報を認証サーバーから保護されたリソースに伝達できます。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7662.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7662で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introspection Endpoint . . . . . . . . . . . . . . . . . . . 3
2.1. Introspection Request . . . . . . . . . . . . . . . . . . 4
2.2. Introspection Response . . . . . . . . . . . . . . . . . 6
2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
3.1. OAuth Token Introspection Response Registry . . . . . . . 9
3.1.1. Registration Template . . . . . . . . . . . . . . . . 10
3.1.2. Initial Registry Contents . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Use with Proof-of-Possession Tokens . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
In OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients. This means that the client does not need to know anything about the content or structure of the token itself, if there is any. However, there is still a large amount of metadata that may be attached to a token, such as its current validity, approved scopes, and information about the context in which the token was issued. These pieces of information are often vital to protected resources making authorization decisions based on the tokens being presented. Since OAuth 2.0 does not define a protocol for the resource server to learn meta-information about a token that it has received from an authorization server, several different approaches have been developed to bridge this gap. These include using structured token formats such as JWT [RFC7519] or proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information.
OAuth 2.0 [RFC6749]では、トークンの内容はクライアントに対して不透明です。これは、クライアントがトークン自体の内容や構造について知っている必要がないことを意味します。ただし、現在の有効性、承認されたスコープ、トークンが発行されたコンテキストに関する情報など、トークンに添付できるメタデータはまだたくさんあります。これらの情報は、提示されたトークンに基づいて承認を決定する保護されたリソースにとって重要な場合がよくあります。 OAuth 2.0は、リソースサーバーが承認サーバーから受け取ったトークンに関するメタ情報を学習するためのプロトコルを定義していないため、このギャップを埋めるためにいくつかの異なるアプローチが開発されています。これらには、JWT [RFC7519]などの構造化トークン形式や、トークン情報を伝達する独自のサービス間通信メカニズム（共有データベースや保護されたエンタープライズサービスバスなど）の使用が含まれます。
This specification defines a protocol that allows authorized protected resources to query the authorization server to determine the set of metadata for a given token that was presented to them by an OAuth 2.0 client. This metadata includes whether or not the token is currently active (or if it has expired or otherwise been revoked), what rights of access the token carries (usually conveyed through OAuth 2.0 scopes), and the authorization context in which the token was granted (including who authorized the token and which client it was issued to). Token introspection allows a protected resource to query this information regardless of whether or not it is carried in the token itself, allowing this method to be used along with or independently of structured token values. Additionally, a protected resource can use the mechanism described in this specification to introspect the token in a particular authorization decision context and ascertain the relevant metadata about the token to make this authorization decision appropriately.
この仕様は、許可された保護リソースが許可サーバーに照会して、OAuth 2.0クライアントから提示された特定のトークンのメタデータのセットを判別できるようにするプロトコルを定義しています。このメタデータには、トークンが現在アクティブであるかどうか（またはトークンが期限切れになっているか、取り消されているかどうか）、トークンが持つアクセス権（通常はOAuth 2.0スコープを通じて伝達される）、およびトークンが付与された承認コンテキスト（トークンの承認者と発行先のクライアントを含む）。トークンイントロスペクションを使用すると、保護されたリソースは、トークン自体に含まれているかどうかに関係なく、この情報をクエリできるため、このメソッドを構造化トークン値と一緒に、または独立して使用できます。さらに、保護されたリソースは、この仕様で説明されているメカニズムを使用して、特定の承認決定コンテキストでトークンをイントロスペクトし、トークンに関する関連メタデータを確認して、この承認決定を適切に行うことができます。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの 'は、[RFC2119]で説明されているように解釈されます。
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
特に明記しない限り、すべてのプロトコルパラメータの名前と値は大文字と小文字が区別されます。
This section defines the terminology used by this specification. This section is a normative portion of this specification, imposing requirements upon implementations.
このセクションでは、この仕様で使用される用語を定義します。このセクションはこの仕様の規範的な部分であり、実装に要件を課します。
This specification uses the terms "access token", "authorization endpoint", "authorization grant", "authorization server", "client", "client identifier", "protected resource", "refresh token", "resource owner", "resource server", and "token endpoint" defined by OAuth 2.0 [RFC6749], and the terms "claim names" and "claim values" defined by JSON Web Token (JWT) [RFC7519].
この仕様では、「アクセストークン」、「承認エンドポイント」、「承認付与」、「承認サーバー」、「クライアント」、「クライアント識別子」、「保護されたリソース」、「更新トークン」、「リソース所有者」、「 OAuth 2.0 [RFC6749]で定義された「リソースサーバー」、「トークンエンドポイント」、JSON Web Token（JWT）[RFC7519]で定義された「クレーム名」と「クレーム値」という用語。
This specification defines the following terms:
この仕様では、次の用語を定義しています。
Token Introspection The act of inquiring about the current state of an OAuth 2.0 token through use of the network protocol defined in this document.
トークンイントロスペクションこのドキュメントで定義されているネットワークプロトコルを使用して、OAuth 2.0トークンの現在の状態を問い合わせる行為。
Introspection Endpoint The OAuth 2.0 endpoint through which the token introspection operation is accomplished.
イントロスペクションエンドポイントトークンイントロスペクション操作が実行されるOAuth 2.0エンドポイント。
The introspection endpoint is an OAuth 2.0 endpoint that takes a parameter representing an OAuth 2.0 token and returns a JSON [RFC7159] document representing the meta information surrounding the token, including whether this token is currently active. The definition of an active token is dependent upon the authorization server, but this is commonly a token that has been issued by this authorization server, is not expired, has not been revoked, and is valid for use at the protected resource making the introspection call.
イントロスペクションエンドポイントはOAuth 2.0エンドポイントであり、OAuth 2.0トークンを表すパラメーターを取り、このトークンが現在アクティブかどうかなど、トークンを取り巻くメタ情報を表すJSON [RFC7159]ドキュメントを返します。アクティブなトークンの定義は許可サーバーに依存しますが、これは通常、この許可サーバーによって発行されたトークンであり、有効期限が切れておらず、取り消されておらず、イントロスペクション呼び出しを行う保護リソースでの使用に有効です。
The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4. The means by which the protected resource discovers the location of the introspection endpoint are outside the scope of this specification.
セクション4で説明されているように、イントロスペクションエンドポイントはトランスポート層セキュリティメカニズムによって保護されなければなりません（MUST）。保護されたリソースがイントロスペクションエンドポイントの場所を発見する手段は、この仕様の範囲外です。
The protected resource calls the introspection endpoint using an HTTP POST [RFC7231] request with parameters sent as "application/x-www-form-urlencoded" data as defined in [W3C.REC-html5-20141028]. The protected resource sends a parameter representing the token along with optional parameters representing additional context that is known by the protected resource to aid the authorization server in its response.
保護されたリソースは、[W3C.REC-html5-20141028]で定義されている「application / x-www-form-urlencoded」データとして送信されたパラメーターを使用して、HTTP POST [RFC7231]リクエストを使用してイントロスペクションエンドポイントを呼び出します。保護されたリソースは、トークンを表すパラメータと、保護されたリソースによって認識される追加のコンテキストを表すオプションのパラメータを送信して、認証サーバーの応答を支援します。
token REQUIRED. The string value of the token. For access tokens, this is the "access_token" value returned from the token endpoint defined in OAuth 2.0 [RFC6749], Section 5.1. For refresh tokens, this is the "refresh_token" value returned from the token endpoint as defined in OAuth 2.0 [RFC6749], Section 5.1. Other token types are outside the scope of this specification.
トークンが必要です。トークンの文字列値。アクセストークンの場合、これはOAuth 2.0 [RFC6749]、セクション5.1で定義されたトークンエンドポイントから返される「access_token」値です。更新トークンの場合、これはOAuth 2.0 [RFC6749]のセクション5.1で定義されているように、トークンエンドポイントから返される「refresh_token」値です。他のトークンタイプは、この仕様の範囲外です。
token_type_hint OPTIONAL. A hint about the type of the token submitted for introspection. The protected resource MAY pass this parameter to help the authorization server optimize the token lookup. If the server is unable to locate the token using the given hint, it MUST extend its search across all of its supported token types. An authorization server MAY ignore this parameter, particularly if it is able to detect the token type automatically. Values for this field are defined in the "OAuth Token Type Hints" registry defined in OAuth Token Revocation [RFC7009].
token_type_hintオプション。イントロスペクションのために送信されたトークンのタイプに関するヒント。保護されたリソースは、許可サーバーがトークンの検索を最適化するのを助けるためにこのパラメーターを渡すことができます。サーバーが指定されたヒントを使用してトークンを見つけることができない場合、サポートされているすべてのトークンタイプにまたがって検索を拡張する必要があります。認可サーバーは、特にトークンタイプを自動的に検出できる場合は、このパラメーターを無視してもよい（MAY）。このフィールドの値は、OAuthトークンの取り消し[RFC7009]で定義されている "OAuth Token Type Hints"レジストリで定義されています。
The introspection endpoint MAY accept other OPTIONAL parameters to provide further context to the query. For instance, an authorization server may desire to know the IP address of the client accessing the protected resource to determine if the correct client is likely to be presenting the token. The definition of this or any other parameters are outside the scope of this specification, to be defined by service documentation or extensions to this specification. If the authorization server is unable to determine the state of the token without additional information, it SHOULD return an introspection response indicating the token is not active as described in Section 2.2.
イントロスペクションエンドポイントは、クエリにさらにコンテキストを提供するために、他のOPTIONALパラメータを受け入れる場合があります。たとえば、承認サーバーは、保護されたリソースにアクセスしているクライアントのIPアドレスを知り、正しいクライアントがトークンを提示している可能性が高いかどうかを判断することを望む場合があります。このパラメータまたは他のパラメータの定義は、この仕様の範囲外であり、サービスドキュメントまたはこの仕様の拡張機能によって定義されます。承認サーバーが追加情報なしでトークンの状態を判別できない場合は、セクション2.2で説明されているように、トークンがアクティブでないことを示すイントロスペクション応答を返す必要があります（SHOULD）。
To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. The methods of managing and validating these authentication credentials are out of scope of this specification.
トークンスキャン攻撃を防ぐために、エンドポイントは、OAuth 2.0 [RFC6749]で説明されているクライアント認証や、OAuth 2.0ベアラートークンで説明されているベアラートークンなどの別のOAuth 2.0アクセストークンなど、このエンドポイントにアクセスするための何らかの形式の承認も必要とします。使用法[RFC6750]。これらの認証資格情報を管理および検証する方法は、この仕様の範囲外です。
For example, the following shows a protected resource calling the token introspection endpoint to query about an OAuth 2.0 bearer token. The protected resource is using a separate OAuth 2.0 bearer token to authorize this call.
たとえば、次の例では、保護されたリソースがトークンイントロスペクションエンドポイントを呼び出してOAuth 2.0ベアラートークンについてクエリを実行しています。保護されたリソースは、この呼び出しを承認するために別のOAuth 2.0ベアラートークンを使用しています。
The following is a non-normative example request:
以下は、規範的でないリクエストの例です。
POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer 23410913-abewfq.123483
token=2YotnFZFEjr1zCsicMWpAA
token = 2YotnFZFEjr1zCsicMWpAA
In this example, the protected resource uses a client identifier and client secret to authenticate itself to the introspection endpoint. The protected resource also sends a token type hint indicating that it is inquiring about an access token.
この例では、保護されたリソースは、クライアント識別子とクライアントシークレットを使用して、イントロスペクションエンドポイントに対して自身を認証します。保護されたリソースは、アクセストークンについて問い合わせていることを示すトークンタイプのヒントも送信します。
The following is a non-normative example request:
以下は、規範的でないリクエストの例です。
POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=mF_9.B5f-4.1JqM&token_type_hint=access_token
token = mF_9.B5f-4.1JqM＆token_type_hint = access_token
The server responds with a JSON object [RFC7159] in "application/ json" format with the following top-level members.
サーバーは、「application / json」形式のJSONオブジェクト[RFC7159]で応答し、次のトップレベルのメンバーを含みます。
active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The specifics of a token's "active" state will vary depending on the implementation of the authorization server and the information it keeps about its tokens, but a "true" value return for the "active" property will generally indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g., after its issuance time and before its expiration time). See Section 4 for information on implementation of such checks.
アクティブが必要です。提示されたトークンが現在アクティブであるかどうかのブールインジケーター。トークンの「アクティブ」状態の詳細は、承認サーバーの実装とトークンについて保持している情報によって異なりますが、「アクティブ」プロパティの「true」値の戻りは、通常、特定のトークンがこの許可サーバーによって発行され、リソース所有者によって取り消されておらず、指定された有効期間内（たとえば、発行時刻後、有効期限前）にある。このようなチェックの実装については、セクション4を参照してください。
scope OPTIONAL. A JSON string containing a space-separated list of scopes associated with this token, in the format described in Section 3.3 of OAuth 2.0 [RFC6749].
スコープオプション。 OAuth 2.0 [RFC6749]のセクション3.3で説明されている形式で、このトークンに関連付けられたスコープのスペース区切りリストを含むJSON文字列。
client_id OPTIONAL. Client identifier for the OAuth 2.0 client that requested this token.
client_idオプション。このトークンを要求したOAuth 2.0クライアントのクライアント識別子。
username OPTIONAL. Human-readable identifier for the resource owner who authorized this token.
ユーザー名オプション。このトークンを承認したリソース所有者の人間が読める識別子。
token_type OPTIONAL. Type of the token as defined in Section 5.1 of OAuth 2.0 [RFC6749].
token_typeオプション。 OAuth 2.0 [RFC6749]のセクション5.1で定義されているトークンのタイプ。
exp OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token will expire, as defined in JWT [RFC7519].
expオプション。 1970年1月1日のUTCからの秒数で測定される整数のタイムスタンプ。JWT[RFC7519]で定義されているように、このトークンがいつ期限切れになるかを示します。
iat OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token was originally issued, as defined in JWT [RFC7519].
iat OPTIONAL。 JWT [RFC7519]で定義されているように、1970年1月1日からの秒数で測定される整数のタイムスタンプ。
nbf OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token is not to be used before, as defined in JWT [RFC7519].
nbfオプション。 JWT [RFC7519]で定義されているように、1970年1月1日からの秒数で測定される整数のタイムスタンプ。このトークンが以前に使用されない場合を示します。
sub OPTIONAL. Subject of the token, as defined in JWT [RFC7519]. Usually a machine-readable identifier of the resource owner who authorized this token.
サブオプション。 JWT [RFC7519]で定義されているトークンの件名。通常、このトークンを承認したリソース所有者の機械可読識別子。
aud OPTIONAL. Service-specific string identifier or list of string identifiers representing the intended audience for this token, as defined in JWT [RFC7519].
audオプション。 JWT [RFC7519]で定義されている、このトークンの対象ユーザーを表すサービス固有の文字列識別子または文字列識別子のリスト。
iss OPTIONAL. String representing the issuer of this token, as defined in JWT [RFC7519].
iss OPTIONAL。 JWT [RFC7519]で定義されている、このトークンの発行者を表す文字列。
jti OPTIONAL. String identifier for the token, as defined in JWT [RFC7519].
jtiオプション。 JWT [RFC7519]で定義されているトークンの文字列識別子。
Specific implementations MAY extend this structure with their own service-specific response names as top-level members of this JSON object. Response names intended to be used across domains MUST be registered in the "OAuth Token Introspection Response" registry defined in Section 3.1.
特定の実装は、このJSONオブジェクトのトップレベルメンバーとして独自のサービス固有の応答名を使用して、この構造を拡張する場合があります。ドメイン間で使用することを目的とした応答名は、セクション3.1で定義された「OAuthトークンイントロスペクション応答」レジストリに登録する必要があります。
The authorization server MAY respond differently to different protected resources making the same request. For instance, an authorization server MAY limit which scopes from a given token are returned for each protected resource to prevent a protected resource from learning more about the larger network than is necessary for its operation.
認可サーバーは、同じリクエストを行う異なる保護リソースに対して異なる応答をする場合があります。たとえば、認証サーバーは、保護されたリソースがその操作に必要なものよりも大きなネットワークについて学習しないように、保護されたリソースごとに、特定のトークンから返されるスコープを制限できます（MAY）。
The response MAY be cached by the protected resource to improve performance and reduce load on the introspection endpoint, but at the cost of liveness of the information used by the protected resource to make authorization decisions. See Section 4 for more information regarding the trade off when the response is cached.
応答は保護されたリソースによってキャッシュされて、パフォーマンスを向上させ、イントロスペクションエンドポイントの負荷を軽減することができますが、保護されたリソースが許可の決定を行うために使用する情報の活性を犠牲にしてください。応答がキャッシュされるときのトレードオフの詳細については、セクション4を参照してください。
For example, the following response contains a set of information about an active token:
たとえば、次の応答には、アクティブなトークンに関する一連の情報が含まれています。
The following is a non-normative example response:
以下は、非規範的な応答例です。
HTTP/1.1 200 OK
Content-Type: application/json
{
"active": true,
"client_id": "l238j323ds-23ij4",
"username": "jdoe",
"scope": "read write dolphin",
"sub": "Z5O3upPC88QrAjx00dis",
"aud": "https://protected.example.net/resource",
"iss": "https://server.example.com/",
"exp": 1419356238,
"iat": 1419350238,
"extension_field": "twenty-seven"
}
If the introspection call is properly authorized but the token is not active, does not exist on this server, or the protected resource is not allowed to introspect this particular token, then the authorization server MUST return an introspection response with the "active" field set to "false". Note that to avoid disclosing too much of the authorization server's state to a third party, the authorization server SHOULD NOT include any additional information about an inactive token, including why the token is inactive.
イントロスペクションコールが適切に承認されているが、トークンがアクティブでない、このサーバーに存在しない、または保護されたリソースがこの特定のトークンのイントロスペクションを許可されていない場合、承認サーバーは「アクティブ」フィールドを設定してイントロスペクション応答を返す必要があります「false」に。承認サーバーの状態の多くを第三者に開示しないようにするため、承認サーバーには、トークンが非アクティブである理由など、非アクティブなトークンに関する追加情報を含めないでください。
The following is a non-normative example response for a token that has been revoked or is otherwise invalid:
以下は、取り消されたトークンまたはそれ以外の場合は無効なトークンの非規範的な応答例です。
HTTP/1.1 200 OK
Content-Type: application/json
{
"active": false
}
If the protected resource uses OAuth 2.0 client credentials to authenticate to the introspection endpoint and its credentials are invalid, the authorization server responds with an HTTP 401 (Unauthorized) as described in Section 5.2 of OAuth 2.0 [RFC6749].
保護されたリソースがOAuth 2.0クライアント認証情報を使用してイントロスペクションエンドポイントへの認証を行い、その認証情報が無効な場合、認証サーバーはOAuth 2.0 [RFC6749]のセクション5.2で説明されているようにHTTP 401（Unauthorized）で応答します。
If the protected resource uses an OAuth 2.0 bearer token to authorize its call to the introspection endpoint and the token used for authorization does not contain sufficient privileges or is otherwise invalid for this request, the authorization server responds with an HTTP 401 code as described in Section 3 of OAuth 2.0 Bearer Token Usage [RFC6750].
保護されたリソースがOAuth 2.0ベアラートークンを使用してイントロスペクションエンドポイントへの呼び出しを承認し、承認に使用されたトークンに十分な特権が含まれていないか、このリクエストに対して無効である場合、承認サーバーはセクションで説明されているようにHTTP 401コードで応答しますOAuth 2.0 Bearer Token Usage [RFC6750]の3つ。
Note that a properly formed and authorized query for an inactive or otherwise invalid token (or a token the protected resource is not allowed to know about) is not considered an error response by this specification. In these cases, the authorization server MUST instead respond with an introspection response with the "active" field set to "false" as described in Section 2.2.
非アクティブなトークンまたはその他の方法で無効なトークン（または保護されたリソースが知ることを許可されていないトークン）に対して適切に形成および承認されたクエリは、この仕様ではエラー応答と見なされないことに注意してください。これらの場合、セクション2.2で説明されているように、認可サーバーは代わりに「アクティブ」フィールドを「false」に設定したイントロスペクション応答で応答する必要があります。
This specification establishes the "OAuth Token Introspection Response" registry.
この仕様は、「OAuthトークンイントロスペクションレスポンス」レジストリを確立します。
OAuth registration client metadata names and descriptions are registered by Specification Required [RFC5226] after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.
OAuth登録クライアントのメタデータの名前と説明は、1名以上のDesignated Expertsの助言により、oauth-ext-review @ ietf.orgメーリングリストで2週間のレビュー期間を経て、Specification Required [RFC5226]によって登録されます。ただし、公開前に名前の割り当てを可能にするために、指定された専門家は、そのような仕様が公開されることに納得したら、登録を承認することができます。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Token Introspection Response name: example").
確認のためにメーリングリストに送信される登録リクエストでは、適切な件名を使用する必要があります（「OAuthトークンイントロスペクションレスポンス名の登録リクエスト：例」など）。
Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
レビュー期間内に、指定された専門家は登録リクエストを承認または拒否し、この決定をレビューリストとIANAに通知します。拒否には、要求を成功させる方法についての説明と、該当する場合は提案を含める必要があります。
IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.
IANAは、指定された専門家からのレジストリの更新のみを受け入れ、登録のすべてのリクエストをレビューメーリングリストに転送する必要があります。
Name: The name requested (e.g., "example"). This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted. Names that match claims registered in the "JSON Web Token Claims" registry established by [RFC7519] SHOULD have comparable definitions and semantics.
名前：リクエストされた名前（例：「example」）。この名前は大文字と小文字が区別されます。大文字と小文字を区別しない方法で他の登録名と一致する名前は受け入れないでください。 [RFC7519]によって確立された「JSON Web Token Claims」レジストリに登録されているクレームと一致する名前は、同等の定義とセマンティクスを持つ必要があります。
Description: Brief description of the metadata value (e.g., "Example description").
説明：メタデータ値の簡単な説明（例：「説明の例」）。
Change controller: For Standards Track RFCs, state "IESG". For other documents, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
コントローラーの変更：Standards Track RFCの場合は、「IESG」と記載します。その他の文書については、責任者の名前を記入してください。その他の詳細（たとえば、住所、電子メールアドレス、ホームページURI）も含まれる場合があります。
Specification document(s): Reference to the document(s) that specify the token endpoint authorization method, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
仕様ドキュメント：トークンエンドポイント認証方法を指定するドキュメントへの参照。ドキュメントのコピーを取得するために使用できるURIを含むことが好ましい。関連セクションの表示も含まれる場合がありますが、必須ではありません。
The initial contents of the "OAuth Token Introspection Response" registry are as follows:
「OAuth Token Introspection Response」レジストリの初期の内容は次のとおりです。
o Name: "active" o Description: Token active status o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「アクティブ」o説明：トークンのアクティブステータスo変更コントローラ：IESG o仕様書：RFC 7662のセクション2.2（このドキュメント）。
o Name: "username" o Description: User identifier of the resource owner o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「username」o説明：リソース所有者のユーザー識別子o変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
o Name: "client_id" o Description: Client identifier of the client o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「client_id」o説明：クライアントのクライアント識別子o変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
o Name: "scope" o Description: Authorized scopes of the token o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「スコープ」o説明：トークンの承認済みスコープo変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
o Name: "token_type" o Description: Type of the token o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前： "token_type" o説明：トークンのタイプo変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
o Name: "exp" o Description: Expiration timestamp of the token o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「exp」o説明：トークンの有効期限タイムスタンプo変更管理者：IESG o仕様文書：RFC 7662のセクション2.2（この文書）。
o Name: "iat" o Description: Issuance timestamp of the token o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「iat」o説明：トークンの発行タイムスタンプo変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
o Name: "nbf" o Description: Timestamp before which the token is not valid o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「nbf」o説明：トークンが無効になる前のタイムスタンプo変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
o Name: "sub" o Description: Subject of the token o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「sub」o説明：トークンの件名o変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
o Name: "aud" o Description: Audience of the token o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「aud」o説明：トークンの対象者o変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
o Name: "iss" o Description: Issuer of the token o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「iss」o説明：トークンの発行者o変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
o Name: "jti" o Description: Unique identifier of the token o Change Controller: IESG o Specification Document(s): Section 2.2 of RFC 7662 (this document).
o 名前：「jti」o説明：トークンの一意の識別子o変更管理者：IESG o仕様書：RFC 7662のセクション2.2（この文書）。
Since there are many different and valid ways to implement an OAuth 2.0 system, there are consequently many ways for an authorization server to determine whether or not a token is currently "active". However, since resource servers using token introspection rely on the authorization server to determine the state of a token, the authorization server MUST perform all applicable checks against a token's state. For instance, these tests include the following:
OAuth 2.0システムを実装するにはさまざまな有効な方法があるため、認可サーバーがトークンが現在「アクティブ」であるかどうかを判断する方法は多数あります。ただし、トークンイントロスペクションを使用するリソースサーバーは、承認サーバーに依存してトークンの状態を判断するため、承認サーバーは、トークンの状態に対して該当するすべてのチェックを実行する必要があります。たとえば、これらのテストには次のものが含まれます。
o If the token can expire, the authorization server MUST determine whether or not the token has expired. o If the token can be issued before it is able to be used, the authorization server MUST determine whether or not a token's valid period has started yet. o If the token can be revoked after it was issued, the authorization server MUST determine whether or not such a revocation has taken place. o If the token has been signed, the authorization server MUST validate the signature. o If the token can be used only at certain resource servers, the authorization server MUST determine whether or not the token can be used at the resource server making the introspection call.
o トークンが期限切れになる可能性がある場合、認可サーバーはトークンが期限切れかどうかを判断する必要があります。 oトークンを使用できるようになる前に発行できる場合、認証サーバーは、トークンの有効期間がまだ始まっているかどうかを判断する必要があります。 oトークンが発行された後でトークンを取り消すことができる場合、認可サーバーは、そのような取り消しが行われたかどうかを判断しなければなりません（MUST）。 oトークンが署名されている場合、承認サーバーは署名を検証する必要があります。 oトークンを特定のリソースサーバーでのみ使用できる場合、承認サーバーは、イントロスペクション呼び出しを行うリソースサーバーでトークンを使用できるかどうかを決定する必要があります。
If an authorization server fails to perform any applicable check, the resource server could make an erroneous security decision based on that response. Note that not all of these checks will be applicable to all OAuth 2.0 deployments and it is up to the authorization server to determine which of these checks (and any other checks) apply.
承認サーバーが該当するチェックを実行できない場合、リソースサーバーはその応答に基づいて誤ったセキュリティ決定を行う可能性があります。これらのチェックのすべてがすべてのOAuth 2.0デプロイメントに適用できるわけではなく、これらのチェック（および他のすべてのチェック）のどれを適用するかを決定するのは承認サーバー次第です。
If left unprotected and un-throttled, the introspection endpoint could present a means for an attacker to poll a series of possible token values, fishing for a valid token. To prevent this, the authorization server MUST require authentication of protected resources that need to access the introspection endpoint and SHOULD require protected resources to be specifically authorized to call the introspection endpoint. The specifics of such authentication credentials are out of scope of this specification, but commonly these credentials could take the form of any valid client authentication mechanism used with the token endpoint, an OAuth 2.0 access token, or other HTTP authorization or authentication mechanism. A single piece of software acting as both a client and a protected resource MAY reuse the same credentials between the token endpoint and the introspection endpoint, though doing so potentially conflates the activities of the client and protected resource portions of the software and the authorization server MAY require separate credentials for each mode.
保護されず、スロットルされないままになっている場合、イントロスペクションエンドポイントは、攻撃者が一連の可能なトークン値をポーリングし、有効なトークンを探す手段を提示する可能性があります。これを防ぐために、承認サーバーは、イントロスペクションエンドポイントにアクセスする必要がある保護されたリソースの認証を必要とします（SHOULD）。このような認証資格情報の詳細はこの仕様の範囲外ですが、通常、これらの資格情報は、トークンエンドポイント、OAuth 2.0アクセストークン、またはその他のHTTP承認または認証メカニズムで使用される有効なクライアント認証メカニズムの形式を取ることができます。クライアントと保護されたリソースの両方として機能する単一のソフトウェアは、トークンエンドポイントとイントロスペクションエンドポイント間で同じ資格情報を再利用できますが、そうすることで、ソフトウェアと承認サーバーのクライアントと保護されたリソース部分のアクティビティが潜在的に拡大する場合があります。モードごとに個別の資格情報が必要です。
Since the introspection endpoint takes in OAuth 2.0 tokens as parameters and responds with information used to make authorization decisions, the server MUST support Transport Layer Security (TLS) 1.2 [RFC5246] and MAY support additional transport-layer mechanisms meeting its security requirements. When using TLS, the client or protected resource MUST perform a TLS/SSL server certificate check, as specified in [RFC6125]. Implementation security considerations can be found in Recommendations for Secure Use of TLS and DTLS [BCP195].
イントロスペクションエンドポイントはOAuth 2.0トークンをパラメーターとして受け取り、承認の決定に使用される情報で応答するため、サーバーはトランスポート層セキュリティ（TLS）1.2 [RFC5246]をサポートする必要があり、セキュリティ要件を満たす追加のトランスポート層メカニズムをサポートする必要があります（MAY）。 TLSを使用する場合、クライアントまたは保護されたリソースは、[RFC6125]で指定されているように、TLS / SSLサーバー証明書チェックを実行する必要があります。実装のセキュリティに関する考慮事項は、TLSおよびDTLSの安全な使用に関する推奨事項[BCP195]に記載されています。
To prevent the values of access tokens from leaking into server-side logs via query parameters, an authorization server offering token introspection MAY disallow the use of HTTP GET on the introspection endpoint and instead require the HTTP POST method to be used at the introspection endpoint.
クエリパラメーターを介してアクセストークンの値がサーバー側のログに漏洩するのを防ぐために、トークンイントロスペクションを提供する承認サーバーは、イントロスペクションエンドポイントでのHTTP GETの使用を許可せず、代わりにイントロスペクションエンドポイントでHTTP POSTメソッドを使用する必要があります。
To avoid disclosing the internal state of the authorization server, an introspection response for an inactive token SHOULD NOT contain any additional claims beyond the required "active" claim (with its value set to "false").
承認サーバーの内部状態の開示を回避するために、非アクティブなトークンのイントロスペクション応答には、必須の「アクティブな」クレーム（値が「false」に設定されている）以外の追加のクレームを含めないでください。
Since a protected resource MAY cache the response of the introspection endpoint, designers of an OAuth 2.0 system using this protocol MUST consider the performance and security trade-offs inherent in caching security information such as this. A less aggressive cache with a short timeout will provide the protected resource with more up-to-date information (due to it needing to query the introspection endpoint more often) at the cost of increased network traffic and load on the introspection endpoint. A more aggressive cache with a longer duration will minimize network traffic and load on the introspection endpoint, but at the risk of stale information about the token. For example, the token may be revoked while the protected resource is relying on the value of the cached response to make authorization decisions. This creates a window during which a revoked token could be used at the protected resource. Consequently, an acceptable cache validity duration needs to be carefully considered given the concerns and sensitivities of the protected resource being accessed and the likelihood of a token being revoked or invalidated in the interim period. Highly sensitive environments can opt to disable caching entirely on the protected resource to eliminate the risk of stale cached information entirely, again at the cost of increased network traffic and server load. If the response contains the "exp" parameter (expiration), the response MUST NOT be cached beyond the time indicated therein.
保護されたリソースはイントロスペクションエンドポイントの応答をキャッシュする場合があるため、このプロトコルを使用するOAuth 2.0システムの設計者は、このようなセキュリティ情報のキャッシュに固有のパフォーマンスとセキュリティのトレードオフを考慮する必要があります。タイムアウトが短い積極性の低いキャッシュを使用すると、ネットワークトラフィックとイントロスペクションエンドポイントの負荷が増加する代わりに、保護されたリソースに（イントロスペクションエンドポイントを頻繁にクエリする必要があるため）最新の情報が提供されます。持続時間が長い積極的なキャッシュを使用すると、ネットワークトラフィックとイントロスペクションエンドポイントの負荷が最小限に抑えられますが、トークンに関する情報が古くなるリスクがあります。たとえば、保護されたリソースがキャッシュされた応答の値に依存して認可を決定している間に、トークンが取り消される場合があります。これにより、取り消されたトークンを保護されたリソースで使用できるウィンドウが作成されます。したがって、アクセスされる保護されたリソースの懸念事項と機密性、およびトークンが暫定的に取り消されるか無効になる可能性を考慮して、許容可能なキャッシュ有効期間を慎重に検討する必要があります。機密性の高い環境では、保護されたリソースのキャッシュを完全に無効にして、キャッシュされた情報が完全に陳腐化するリスクを完全になくすことができますが、ネットワークトラフィックとサーバーの負荷が増大します。応答に「exp」パラメーター（有効期限）が含まれている場合、その応答は、そこに示されている時間を超えてキャッシュしてはなりません（MUST NOT）。
An authorization server offering token introspection must be able to understand the token values being presented to it during this call. The exact means by which this happens is an implementation detail and is outside the scope of this specification. For unstructured tokens, this could take the form of a simple server-side database query against a data store containing the context information for the token. For structured tokens, this could take the form of the server parsing the token, validating its signature or other protection mechanisms, and returning the information contained in the token back to the protected resource (allowing the protected resource to be unaware of the token's contents, much like the client). Note that for tokens carrying encrypted information that is needed during the introspection process, the authorization server must be able to decrypt and validate the token to access this information. Also note that in cases where the authorization server stores no information about the token and has no means of accessing information about the token by parsing the token itself, it cannot likely offer an introspection service.
トークンイントロスペクションを提供する認証サーバーは、この呼び出し中に提示されるトークン値を理解できる必要があります。これが発生する正確な手段は実装の詳細であり、この仕様の範囲外です。非構造化トークンの場合、これは、トークンのコンテキスト情報を含むデータストアに対する単純なサーバー側データベースクエリの形式をとることがあります。構造化トークンの場合、これはサーバーがトークンを解析し、その署名またはその他の保護メカニズムを検証し、トークンに含まれる情報を保護リソースに返す（保護リソースがトークンの内容を認識できないようにする）クライアントのように）。イントロスペクションプロセス中に必要な暗号化された情報を運ぶトークンの場合、認可サーバーはこの情報にアクセスするためにトークンを復号化および検証できる必要があります。また、承認サーバーがトークンに関する情報を保存せず、トークン自体を解析してトークンに関する情報にアクセスする手段がない場合は、イントロスペクションサービスを提供できない可能性があります。
The introspection response may contain privacy-sensitive information such as user identifiers for resource owners. When this is the case, measures MUST be taken to prevent disclosure of this information to unintended parties. One method is to transmit user identifiers as opaque service-specific strings, potentially returning different identifiers to each protected resource.
イントロスペクション応答には、リソース所有者のユーザー識別子など、プライバシーに敏感な情報が含まれる場合があります。この場合、意図しない関係者へのこの情報の開示を防ぐための対策を講じる必要があります。 1つの方法は、ユーザー識別子を不透明なサービス固有の文字列として送信し、保護されている各リソースに異なる識別子を返す可能性があります。
If the protected resource sends additional information about the client's request to the authorization server (such as the client's IP address) using an extension of this specification, such information could have additional privacy considerations that the extension should detail. However, the nature and implications of such extensions are outside the scope of this specification.
保護されたリソースがこの仕様の拡張機能を使用してクライアントのリクエストに関する追加情報（クライアントのIPアドレスなど）を承認サーバーに送信する場合、そのような情報には、拡張機能が詳述する追加のプライバシーに関する考慮事項がある可能性があります。ただし、そのような拡張の性質と意味は、この仕様の範囲外です。
Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues.
イントロスペクションレスポンスからプライバシーの機密情報を除外することは、プライバシーの問題を最小限に抑える最も簡単な方法です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <http://www.rfc-editor.org/info/rfc6750>.
[RFC6750]ジョーンズ、M。およびD.ハート、「OAuth 2.0 Authorization Framework：Bearer Token Usage」、RFC 6750、DOI 10.17487 / RFC6750、2012年10月、<http://www.rfc-editor.org/info/ rfc6750>。
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <http://www.rfc-editor.org/info/rfc7009>.
[RFC7009] Lodderstedt、T.、Ed。、Dronia、S。、およびM. Scurtescu、「OAuth 2.0トークンの取り消し」、RFC 7009、DOI 10.17487 / RFC7009、2013年8月、<http：//www.rfc-editor。 org / info / rfc7009>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.
[RFC7519]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<http://www.rfc-editor.org / info / rfc7519>。
[W3C.REC-html5-20141028] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Navara, E., 0'Connor, E., and S. Pfeiffer, "HTML5", World Wide Web Consortium Recommendation REC-html5-20141028, October 2014, <http://www.w3.org/TR/2014/REC-html5-20141028>.
[W3C.REC-html5-20141028] Hickson、I.、Berjon、R.、Faulkner、S.、Leithead、T.、Navara、E.、0'Connor、E.、and S. Pfeiffer、 "HTML5"、 World Wide Web Consortium Recommendation REC-html5-20141028、2014年10月、<http://www.w3.org/TR/2014/REC-html5-20141028>。
[BCP195] 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, May 2015, <http://www.rfc-editor.org/info/bcp195>.
[BCP195] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、2015年5月、<http://www.rfc-editor.org/info/bcp195>。
With bearer tokens such as those defined by OAuth 2.0 Bearer Token Usage [RFC6750], the protected resource will have in its possession the entire secret portion of the token for submission to the introspection service. However, for proof-of-possession style tokens, the protected resource will have only a token identifier used during the request, along with the cryptographic signature on the request. To validate the signature on the request, the protected resource could be able to submit the token identifier to the authorization server's introspection endpoint to obtain the necessary key information needed for that token. The details of this usage are outside the scope of this specification and will be defined in an extension to this specification in concert with the definition of proof-of-possession tokens.
OAuth 2.0ベアラートークンの使用法[RFC6750]で定義されているようなベアラートークンを使用すると、保護されたリソースは、イントロスペクションサービスに送信するためにトークンの秘密部分全体を所有します。ただし、所有証明のスタイルのトークンの場合、保護されたリソースには、要求時に使用されるトークン識別子と、要求の暗号署名のみが含まれます。リクエストの署名を検証するために、保護されたリソースは、トークン識別子を承認サーバーのイントロスペクションエンドポイントに送信して、そのトークンに必要な必要なキー情報を取得できます。この使用法の詳細はこの仕様の範囲外であり、所有証明トークンの定義と連携してこの仕様の拡張で定義されます。
Acknowledgements
謝辞
Thanks to the OAuth Working Group and the User Managed Access Working Group for feedback and review of this document, and to the various implementors of both the client and server components of this specification. In particular, the author would like to thank Amanda Anganes, John Bradley, Thomas Broyer, Brian Campbell, George Fletcher, Paul Freemantle, Thomas Hardjono, Eve Maler, Josh Mandel, Steve Moore, Mike Schwartz, Prabath Siriwardena, Sarah Squire, and Hannes Tschofennig.
このドキュメントのフィードバックとレビューを行ったOAuthワーキンググループとユーザー管理アクセスワーキンググループ、およびこの仕様のクライアントコンポーネントとサーバーコンポーネントの両方のさまざまな実装者に感謝します。特に、著者はアマンダ・アンガネス、ジョン・ブラッドリー、トーマス・ブロイヤー、ブライアン・キャンベル、ジョージ・フレッチャー、ポール・フリーマントル、トーマス・ハードジョノ、イブ・マラー、ジョシュ・マンデル、スティーブ・ムーア、マイク・シュワルツ、プラバス・シリワレナ、サラ・スクワイア、そしてハネスに感謝しますTschofennig。
Author's Address
著者のアドレス
Justin Richer (editor)
ジャスティン・リチャー（編集者）
Email: ietf@justin.richer.org