Internet Engineering Task Force (IETF) T. Lodderstedt, Ed.
Request for Comments: 9701 yes.com AG
Category: Standards Track V. Dzhuvinov
ISSN: 2070-1721 Connect2id Ltd.
January 2025
This specification proposes an additional response secured by JSON Web Token (JWT) for OAuth 2.0 Token Introspection.
この仕様では、OAuth 2.0トークンイントロスペクションのJSON Webトークン（JWT）によって保護された追加の応答を提案します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9701.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9701で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Notation
3. Resource Server Management
4. Requesting a JWT Response
5. JWT Response
6. Client Metadata
7. Authorization Server Metadata
8. Security Considerations
8.1. Cross-JWT Confusion
8.2. Token Data Leakage
9. Privacy Considerations
10. IANA Considerations
10.1. OAuth Dynamic Client Registration Metadata Registration
10.1.1. Registry Contents
10.2. OAuth Authorization Server Metadata Registration
10.2.1. Registry Contents
10.3. Media Type Registration
10.3.1. Registry Contents
10.4. JWT Claim Registration
10.4.1. Registry Contents
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
"OAuth 2.0 Token Introspection" [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token. This enables deployments to implement opaque access tokens in an interoperable way.
「OAUTH 2.0トークンイントロスペクション」[RFC7662]は、保護されたリソースがOAUTH 2.0 Authorization Serverを照会して、アクセストークンの状態を決定し、アクセストークンに関連付けられたデータを取得する方法を指定します。これにより、展開が相互運用可能な方法で不透明アクセストークンを実装できます。
The introspection response, as specified in "OAuth 2.0 Token Introspection" [RFC7662], is a plain JSON object. However, there are use cases where the resource server requires stronger assurance that the authorization server issued the token introspection response for an access token, including cases where the authorization server assumes liability for the content of the token introspection response. An example is a resource server using verified personal data to create certificates, which in turn are used to create qualified electronic signatures.
「OAuth 2.0トークンイントロスペクション」[RFC7662]で指定されているイントロスペクション応答は、単純なJSONオブジェクトです。ただし、リソースサーバーが、認証サーバーがトークンイントロスペクション反応の内容の責任を引き受ける場合を含む、アクセストークンのトークンイントロスペクション応答を発行したというより強力な保証を必要とするユースケースがあります。例としては、検証済みの個人データを使用して証明書を作成するリソースサーバーがあります。これは、適格な電子署名を作成するために使用されます。
In such use cases, it may be useful or even required to return a signed JWT [RFC7519] as the introspection response. This specification extends the token introspection endpoint with the capability to return responses as JWTs.
このようなユースケースでは、イントロスペクション応答として署名されたJWT [RFC7519]を返すことが有用であるか、さらには必要な場合があります。この仕様は、JWTSとして応答を返す機能を備えたトークンイントロスペクションエンドポイントを拡張します。
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] で説明されているように解釈されます。
The authorization server (AS) and the resource server (RS) maintain a strong, two-way trust relationship. The resource server relies on the authorization server to obtain authorization, user, and other data as input to its access control decisions and service delivery. The authorization server relies on the resource server to handle the provided data appropriately.
Authorization Server（AS）およびResource Server（RS）は、強力な双方向の信頼関係を維持しています。リソースサーバーは、Authorization Serverに依存して、アクセス制御の決定とサービス提供への入力として認証、ユーザー、およびその他のデータを取得します。Authorization Serverは、提供されたデータを適切に処理するためにリソースサーバーに依存しています。
In the context of this specification, the token introspection endpoint is used to convey such security data and potentially also privacy-sensitive data related to an access token.
この仕様のコンテキストでは、トークンイントロスペクションのエンドポイントを使用して、そのようなセキュリティデータを伝達し、アクセストークンに関連するプライバシーに敏感なデータも伝えます。
In order to process the introspection requests in a secure and privacy-preserving manner, the authorization server MUST be able to identify, authenticate, and authorize resource servers.
イントロスペクション的要求を安全でプライバシーに基づいた方法で処理するために、認証サーバーはリソースサーバーを識別、認証、認証できる必要があります。
The AS MAY additionally encrypt the token introspection response JWTs. If encryption is used, the AS is provisioned with encryption keys and algorithms for the RS.
ASは、さらにトークンイントロスペクション応答JWTSを暗号化する場合があります。暗号化が使用される場合、ASはRsの暗号化キーとアルゴリズムでプロビジョニングされます。
The AS MUST be able to determine whether an RS is the audience for a particular access token and what data it is entitled to receive; otherwise, the RS is not authorized to obtain data for the access token. The AS has the discretion of how to fulfill this requirement. The AS could, for example, maintain a mapping between scope values and RSs.
ASは、RSが特定のアクセストークンの視聴者であるかどうか、および受信する資格のあるデータを決定できる必要があります。それ以外の場合、RSはアクセストークンのデータを取得する権限がありません。この要件を満たす方法の裁量があります。たとえば、スコープ値とRSSの間のマッピングを維持できる可能性があります。
The requirements given above imply that the AS maintains credentials and other configuration data for each RS.
上記の要件は、ASが各RSの資格情報およびその他の構成データを維持することを意味します。
One way is by utilizing dynamic client registration [RFC7591] and treating every RS as an OAuth client. In this case, the AS is assumed to at least maintain a "client_id" and a "token_endpoint_auth_method" with complementary authentication method metadata, such as "jwks" or "client_secret". In cases where the AS needs to acquire consent to transmit data to an RS, the following client metadata fields are recommended: "client_name", "client_uri", "contacts", "tos_uri", and "policy_uri".
1つの方法は、ダイナミッククライアント登録[RFC7591]を利用し、すべてのRSをOAUTHクライアントとして扱うことです。この場合、ASは、少なくとも「JWKS」や「Client_Secret」などの補完的な認証メソッドメタデータを使用して、少なくとも「client_id」と「token_endpoint_auth_method」を維持すると想定されています。データをRSに送信する必要がある場合に必要な場合、次のクライアントメタデータフィールドが推奨されます：「client_name」、「client_uri」、「contacts」、「tos_uri」、および「policy_uri」。
The AS MUST restrict the use of client credentials by an RS to the calls it requires, e.g., the AS MAY restrict such a client to call the token introspection endpoint only. How the AS implements this restriction is beyond the scope of this specification.
ASは、RSによるクライアント資格情報の使用を必要とする呼び出しに制限する必要があります。この制限がこの仕様の範囲を超えている方法。
This specification further introduces client metadata to manage the configuration options required to sign and encrypt token introspection response JWTs.
この仕様では、クライアントメタデータをさらに導入して、トークンイントロスペクション応答JWTSに署名して暗号化するために必要な構成オプションを管理します。
An RS requests a JWT introspection response by sending an introspection request with an Accept HTTP header field set to "application/token-introspection+jwt".
RSは、「Application/Token-Intropection+JWT」に設定されたAccept HTTPヘッダーフィールドを使用してイントロスペクションリクエストを送信することにより、JWTイントロスペクション応答を要求します。
The AS MUST authenticate the caller at the token introspection endpoint. Authentication can utilize client authentication methods or a separate access token that is issued to the RS and identifies the RS as the subject.
ASは、トークンイントロスペクションエンドポイントで発信者を認証する必要があります。認証は、RSに発行され、RSを主題として識別するクライアント認証方法または個別のアクセストークンを利用できます。
The following is a non-normative example request, with the RS authenticating with a private key JWT:
以下は、非規範的な例リクエストであり、RSは秘密のキーJWTで認証されています。
POST /introspect HTTP/1.1
Host: as.example.com
Accept: application/token-introspection+jwt
Content-Type: application/x-www-form-urlencoded
token=2YotnFZFEjr1zCsicMWpAA&
client_assertion_type=
urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT
The introspection endpoint responds with a JWT, setting the Content-Type HTTP header field to "application/token-introspection+jwt" and the JWT typ ("type") header parameter to "token-introspection+jwt".
イントロスペクションエンドポイントはJWTで応答し、コンテンツタイプのHTTPヘッダーフィールドを「application/token-introspection+jwt」に設定し、JWT Typ（「Type」）ヘッダーパラメーターに「token-introspection+jwt」に設定します。
The JWT MUST include the following top-level claims:
JWTには、次のトップレベルのクレームを含める必要があります。
iss
ISS
MUST be set to the issuer URL of the authorization server.
Authorization Serverの発行者URLに設定する必要があります。
aud
aud
MUST identify the resource server receiving the token introspection response.
トークンイントロスペクション応答を受信するリソースサーバーを特定する必要があります。
iat
IAT
MUST be set to the time when the introspection response was created by the authorization server
イントロスペクション応答が承認サーバーによって作成された時間に設定する必要があります
token_introspection
token_intropection
A JSON object containing the members of the token introspection response, as specified in [RFC7662], Section 2.2. The separation of the introspection response members into a dedicated JSON object containing a JWT claim is intended to prevent conflict and confusion with top-level JWT claims that may bear the same name.
[RFC7662]で指定されているトークンイントロスペクション応答のメンバーを含むJSONオブジェクト、セクション2.2。JWTクレームを含む専用のJSONオブジェクトへのイントロスペクション応答メンバーの分離は、同じ名前を持つ可能性のあるトップレベルのJWTクレームとの紛争と混乱を防ぐことを目的としています。
If the access token is invalid, expired, revoked, or not intended for the calling resource server (audience), the authorization server MUST set the value of the active member in the token_introspection claim to false and MUST NOT include other members. Otherwise, the active member is set to true.
アクセストークンが無効、期限切れ、取り消された、または呼び出しリソースサーバー（オーディエンス）を対象としていない場合、承認サーバーは、token_intropectionのアクティブメンバーの値をfalseに請求する必要があり、他のメンバーを含めてはなりません。それ以外の場合、アクティブなメンバーはtrueに設定されています。
The AS SHOULD narrow down the scope value to the scopes relevant to the particular RS.
ASは、特定のRsに関連するスコープにスコープ値を絞り込む必要があります。
As specified in Section 2.2 of [RFC7662], implementations MAY extend the token introspection response with service-specific claims. In the context of this specification, such claims will be added as top-level members of the token_introspection claim.
[RFC7662]のセクション2.2で指定されているように、実装は、サービス固有のクレームを使用してトークンイントロスペクション応答を拡張する場合があります。この仕様の文脈では、そのようなクレームは、token_intropectionクレームのトップレベルメンバーとして追加されます。
Token introspection response parameter names intended to be used across domains MUST be registered in the "OAuth Token Introspection Response" registry [IANA.OAuth.Token.Introspection] defined by [RFC7662].
ドメイン全体で使用することを目的としたトークンイントロスペクション応答パラメーター名は、[rfc7662]で定義された「OAuthトークンイントロスペクション応答」レジストリ[iana.oauth.token.intropection]に登録する必要があります。
When the AS acts as a provider of resource owner identity claims to the RS, the AS determines, based on its RS-specific policy, what identity claims to return in the token introspection response. The AS MUST ensure the release of any privacy-sensitive data is legally based (see Section 9).
ASがリソース所有者のアイデンティティのプロバイダーとして機能する場合、RSをrsに請求する場合、RS固有のポリシーに基づいて、Token Introspection Responseに戻ると主張するアイデンティティが決定されます。ASは、プライバシーに敏感なデータのリリースが法的に基づいていることを確認する必要があります（セクション9を参照）。
Further content of the introspection response is determined by the RS-specific policy at the AS.
イントロスペクション応答のさらなる内容は、ASでのRS固有のポリシーによって決定されます。
The JWT MAY include other claims, including those from the "JSON Web Token Claims" registry established by [RFC7519]. The JWT SHOULD NOT include the sub and exp claims, as an additional measure to prevent misuse of the JWT as an access token (see Section 8.1).
JWTには、[RFC7519]によって確立された「JSON Webトークンクレーム」レジストリの請求を含む他のクレームが含まれる場合があります。JWTには、JWTのアクセストークンとしての誤用を防ぐための追加の措置として、SubおよびExpクレームを含めるべきではありません（セクション8.1を参照）。
Note: Although the JWT format is widely used as an access token format, the JWT returned in the introspection response is not an alternative representation of the introspected access token and is not intended to be used as an access token.
注：JWT形式はアクセストークン形式として広く使用されていますが、イントロスペクション応答で返されたJWTは、イントロスペクション的アクセストークンの代替表現ではなく、アクセストークンとして使用することを意図していません。
This specification registers the "application/token-introspection+jwt" media type, which is used as the value of the typ ("type") header parameter of the JWT to indicate that the payload is a token introspection response.
この仕様は、「application/token-introspection+jwt」メディアタイプを登録します。これは、ペイロードがトークンイントロスペクション応答であることを示すために、JWTのtyp（ "type"）ヘッダーパラメーターの値として使用されます。
The JWT is cryptographically secured as specified in [RFC7519].
JWTは[RFC7519]で指定されているように暗号化されています。
Depending on the specific resource server policy, the JWT is either signed or signed and encrypted. If the JWT is signed and encrypted, it MUST be a Nested JWT, as defined in JWT [RFC7519].
特定のリソースサーバーポリシーに応じて、JWTは署名または署名および暗号化されています。JWTが署名および暗号化されている場合、JWT [RFC7519]で定義されているように、それはネストされたJWTでなければなりません。
Note: An AS compliant with this specification MUST refuse to serve introspection requests that don't authenticate the caller and return an HTTP status code 400. This is done to ensure token data is released to legitimate recipients only and prevent downgrading to [RFC7662] behavior (see Section 8.2).
注：この仕様に準拠していると、発信者に認証されておらず、HTTPステータスコード400を返すイントロスペクションリクエストの提供を拒否する必要があります。これは、トークンデータが正当な受信者のみにリリースされ、[RFC7662]の格下げを防ぐために行われます。（セクション8.2を参照）。
The following is a non-normative example response (with line breaks for display purposes only):
以下は、非規範的な例の応答です（表示目的でのみラインブレークがあります）：
HTTP/1.1 200 OK
Content-Type: application/token-introspection+jwt
eyJraWQiOiJ3RzZEIiwidHlwIjoidG9rZW4taW50cm9zcGVjdGlvbitqd3QiLCJhbGc
iOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2FzLmV4YW1wbGUuY29tLyIsImF1ZCI6I
mh0dHBzOi8vcnMuZXhhbXBsZS5jb20vcmVzb3VyY2UiLCJpYXQiOjE1MTQ3OTc4OTIs
InRva2VuX2ludHJvc3BlY3Rpb24iOnsiYWN0aXZlIjp0cnVlLCJpc3MiOiJodHRwczo
vL2FzLmV4YW1wbGUuY29tLyIsImF1ZCI6Imh0dHBzOi8vcnMuZXhhbXBsZS5jb20vcm
Vzb3VyY2UiLCJpYXQiOjE1MTQ3OTc4MjIsImV4cCI6MTUxNDc5Nzk0MiwiY2xpZW50X
2lkIjoicGFpQjJnb28wYSIsInNjb3BlIjoicmVhZCB3cml0ZSBkb2xwaGluIiwic3Vi
IjoiWjVPM3VwUEM4OFFyQWp4MDBkaXMiLCJiaXJ0aGRhdGUiOiIxOTgyLTAyLTAxIiw
iZ2l2ZW5fbmFtZSI6IkpvaG4iLCJmYW1pbHlfbmFtZSI6IkRvZSIsImp0aSI6InQxRm
9DQ2FaZDRYdjRPUkpVV1ZVZVRaZnNLaFczMENRQ3JXRERqd1h5NncifX0.przJMU5Gh
mNzvwtt1Sr-xa9xTkpiAg5IshbQsRiRVP_7eGR1GHYrNwQh84kxOkHCyje2g5WSRcYo
sGEVIiC-eoPJJ-qBwqwSlgx9JEeCDw2W5DjrblOI_N0Jvsq_dUeOyoWVMqlOydOBhKN
Y0smBrI4NZvEExucOm9WUJXMuJtvq1gBes-0go5j4TEv9sOP9uu81gqWTr_LOo6pgT0
tFFyZfWC4kbXPXiQ2YT6mxCiQRRNM-l9cBdF6Jx6IOrsfFhBuYdYQ_mlL19HgDDOFal
eyqmru6lKlASOsaE8dmLSeKcX91FbG79FKN8un24iwIDCbKT9xlUFl54xWVShNDFA
The example response JWT header contains the following JSON document:
例の応答JWTヘッダーには、次のJSONドキュメントが含まれています。
{
"typ": "token-introspection+jwt",
"alg": "RS256",
"kid": "wG6D"
}
The example response JWT payload contains the following JSON document:
例の応答JWTペイロードには、次のJSONドキュメントが含まれています。
{
"iss":"https://as.example.com/",
"aud":"https://rs.example.com/resource",
"iat":1514797892,
"token_introspection":
{
"active":true,
"iss":"https://as.example.com/",
"aud":"https://rs.example.com/resource",
"iat":1514797822,
"exp":1514797942,
"client_id":"paiB2goo0a",
"scope":"read write dolphin",
"sub":"Z5O3upPC88QrAjx00dis",
"birthdate":"1982-02-01",
"given_name":"John",
"family_name":"Doe",
"jti":"t1FoCCaZd4Xv4ORJUWVUeTZfsKhW30CQCrWDDjwXy6w"
}
}
The authorization server determines the algorithm to secure the JWT for a particular introspection response. This decision can be based on registered metadata parameters for the resource server, supplied via dynamic client registration [RFC7591] with the resource server acting as a client, as specified below.
Authorization Serverは、特定のイントロスペクション応答のためにJWTを保護するためのアルゴリズムを決定します。この決定は、以下に指定されているように、クライアントとして機能するリソースサーバーを使用して、ダイナミッククライアント登録[RFC7591]を介して提供されるリソースサーバーの登録されたメタデータパラメーターに基づいています。
The parameter names follow the pattern established by OpenID Connect Dynamic Client Registration [OpenID.Registration] for configuring signing and encryption algorithms for JWT responses at the UserInfo endpoint.
パラメーター名は、userInfoエンドポイントでJWT応答の署名および暗号化アルゴリズムを構成するために、OpenID Connect Dynamic Client登録[OpenID.Registration]によって確立されたパターンに従います。
The following client metadata parameters are introduced by this specification:
次のクライアントメタデータパラメーターは、この仕様によって紹介されます。
introspection_signed_response_alg
introspection_signed_response_alg
OPTIONAL. "JSON Web Signature (JWS)" [RFC7515] algorithm (alg value), as defined in "JSON Web Algorithms (JWA)" [RFC7518], for signing introspection responses. If this is specified, the response will be signed using JWS and the configured algorithm. The default, if omitted, is RS256.
オプション。「JSON Web Signature（JWS）」[RFC7515]アルゴリズム（ALG値）、「JSON Webアルゴリズム（JWA）」[RFC7518]で定義されています。これが指定されている場合、応答はJWSと構成されたアルゴリズムを使用して署名されます。省略した場合、デフォルトはRS256です。
introspection_encrypted_response_alg
introspection_encrypted_response_alg
OPTIONAL. "JSON Web Encryption (JWE)" [RFC7516] algorithm (alg value), as defined in JWA [RFC7518], for content key encryption. If this is specified, the response will be encrypted using JWE and the configured content encryption algorithm (introspection_encrypted_response_enc). The default, if omitted, is that no encryption is performed. If both signing and encryption are requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in JWT [RFC7519].
オプション。「JSON Web暗号化（JWE）」[RFC7516]アルゴリズム（ALG値）、JWA [RFC7518]で定義され、コンテンツキー暗号化。これが指定されている場合、応答はJWEと構成されたコンテンツ暗号化アルゴリズム（Introspection_encrypted_response_enc）を使用して暗号化されます。デフォルトは、省略した場合、暗号化が実行されないことです。署名と暗号化の両方が要求されると、応答が署名され、暗号化され、結果はJWT [RFC7519]で定義されているように、ネストされたJWTです。
introspection_encrypted_response_enc
Introspection_encrypted_response_enc
OPTIONAL. JWE [RFC7516] algorithm (enc value), as defined in JWA [RFC7518], for content encryption of introspection responses. The default, if omitted, is A128CBC-HS256. Note: This parameter MUST NOT be specified without setting introspection_encrypted_response_alg.
オプション。JWA [RFC7516]アルゴリズム（ENC値）、JWA [RFC7518]で定義されているように、イントロスペクション反応のコンテンツ暗号化。デフォルトは、省略されている場合、A128CBC-HS256です。注：このパラメーターは、introspection_encrypted_response_algを設定せずに指定してはなりません。
Resource servers may register their public encryption keys using the jwks_uri or jwks metadata parameters.
リソースサーバーは、JWKS_URIまたはJWKSメタデータパラメーターを使用して、パブリック暗号化キーを登録できます。
Authorization servers SHOULD publish the supported algorithms for signing and encrypting the JWT of an introspection response by utilizing "OAuth 2.0 Authorization Server Metadata" [RFC8414] parameters. Resource servers use this data to parametrize their client registration requests.
承認サーバーは、「OAUTH 2.0 Authorization Server Metadata」[RFC8414]パラメーターを使用して、イントロスペクション応答のJWTに署名および暗号化するためのサポートされているアルゴリズムを公開する必要があります。リソースサーバーは、このデータを使用して、クライアントの登録要求をパラメーター化します。
The following parameters are introduced by this specification:
次のパラメーターは、この仕様によって導入されています。
introspection_signing_alg_values_supported
introspection_singe_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS [RFC7515] signing algorithms (alg values), as defined in JWA [RFC7518], supported by the introspection endpoint to sign the response.
オプション。JWA [RFC7515]署名アルゴリズム（ALG値）のリストを含むJSONアレイ、JWA [RFC7518]で定義されているように、イントロスペクションエンドポイントによってサポートされて応答に署名します。
introspection_encryption_alg_values_supported
Introspection_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE [RFC7516] encryption algorithms (alg values), as defined in JWA [RFC7518], supported by the introspection endpoint to encrypt the content encryption key for introspection responses (content key encryption).
オプション。JWA [RFC7516] JWA [RFC7518]で定義されているJWE [RFC7516]暗号化アルゴリズム（ALG値）のリストを含むJSONアレイは、イントロスペクション的エンドポイントでサポートされ、イントロスペクション的エンドポイントによってサポートされています（コンテンツキー暗号化）。
introspection_encryption_enc_values_supported
Introspection_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE [RFC7516] encryption algorithms (enc values), as defined in JWA [RFC7518], supported by the introspection endpoint to encrypt the response (content encryption).
オプション。JWA [RFC7516]暗号化アルゴリズム（ENC値）のリストを含むJSONアレイは、JWA [RFC7518]で定義されており、イントロスペクションエンドポイントによってサポートされて応答（コンテンツ暗号化）を暗号化します。
The iss and potentially the aud claim of a token introspection JWT can resemble those of a JWT-encoded access token. An attacker could try to exploit this and pass a JWT token introspection response as an access token to the resource server. The typ ("type") JWT header "token-introspection+jwt" and the encapsulation of the token introspection members, such as sub and scope in the token_introspection claim, are intended to prevent such substitution attacks. Resource servers MUST therefore check the typ JWT header value of received JWT-encoded access tokens and ensure all minimally required claims for a valid access token are present.
ISSおよび潜在的には、トークンイントロスペクションのJWTのOUD請求は、JWTエンコードされたアクセストークンのOUDに似ている可能性があります。攻撃者は、これを悪用し、JWTトークンイントロスペクション応答をリソースサーバーへのアクセストークンとして渡そうとすることができます。typ（ "Type"）JWT Header "Token-intropection+JWT"およびToken_intropectionクレームのサブや範囲などのトークン内注文メンバーのカプセル化は、そのような代替攻撃を防ぐことを目的としています。したがって、リソースサーバーは、受信したJWTエンコードアクセストークンのTyp JWTヘッダー値を確認し、有効なアクセストークンに必要な最小限の請求がすべて存在することを確認する必要があります。
Resource servers MUST additionally apply the countermeasures against access token replay, as described in [RFC9700].
[RFC9700]で説明されているように、リソースサーバーはさらに、アクセストークンリプレイに対して対策を適用する必要があります。
JWT confusion and other attacks involving JWTs are discussed in [RFC8725].
JWTの混乱とJWTを含むその他の攻撃については、[RFC8725]で説明しています。
The authorization server MUST use Transport Layer Security (TLS) 1.2 (or higher), per BCP 195 [RFC9325], in order to prevent token data leakage.
承認サーバーは、トークンデータの漏れを防ぐために、BCP 195 [RFC9325]ごとに、Transport Layer Security（TLS）1.2（またはそれ以上）を使用する必要があります。
Section 2.1 of [RFC7662] permits requests to the introspection endpoint to be authorized with an access token that doesn't identify the caller. To prevent introspection of tokens by parties that are not the intended consumer, the authorization server MUST require all requests to the token introspection endpoint to be authenticated.
[RFC7662]のセクション2.1は、発信者を識別しないアクセストークンでイントロスペクションエンドポイントにリクエストを許可することを許可しています。意図した消費者ではない当事者によるトークンのイントロスペクションを防ぐために、承認サーバーは、トークンイントロスペクションのエンドポイントへのすべての要求を認証する必要があります。
The token introspection response can be used to transfer personal identifiable information (PII) from the AS to the RS. The AS MUST conform to legal and jurisdictional constraints for the data transfer before any data is released to a particular RS. The details and determining of these constraints vary by jurisdiction and are outside the scope of this document.
トークンイントロスペクション応答を使用して、Rsから個人識別可能な情報（PII）を転送できます。ASは、データが特定のRsにリリースされる前に、データ転送の法的および管轄区域の制約に準拠する必要があります。これらの制約の詳細と決定は、管轄区域によって異なり、このドキュメントの範囲外です。
A commonly found way to establish the legal basis for releasing PII is by explicit user consent gathered from the resource owner by the AS during the authorization flow.
PIIをリリースするための法的根拠を確立するための一般的に発見された方法は、認可フロー中にASによってリソース所有者から収集された明示的なユーザー同意によるものです。
It is also possible that the legal basis is established out of band, for example, in an explicit contract or by the client gathering the resource owner's consent.
また、明示的な契約や、リソース所有者の同意を収集するクライアントによって、法的根拠がバンドから確立される可能性もあります。
If the AS and the RS belong to the same legal entity (1st party scenario), there is potentially no need for an explicit user consent, but the terms of service and policy of the respective service provider MUST be enforced at all times.
ASとRSが同じ法人（第1党シナリオ）に属している場合、明示的なユーザーの同意は必要ない可能性がありますが、それぞれのサービスプロバイダーのサービス条件とポリシーを常に実施する必要があります。
In any case, the AS MUST ensure that the scope of the legal basis is enforced throughout the whole process. The AS MUST retain the scope of the legal basis with the access token, e.g., in the scope value, it MUST authenticate the RS, and the AS MUST determine the data an RS is allowed to receive based on the RS's identity and suitable token data, e.g., the scope value.
いずれにせよ、ASは、法的根拠の範囲がプロセス全体を通して施行されることを保証する必要があります。ASは、アクセストークン、たとえばスコープ値のアクセストークンを使用して法的根拠の範囲を保持する必要があります。RSを認証する必要があり、ASはRSのIDと適切なトークンデータに基づいて受信できるデータを決定する必要があります。、例えば、スコープ値。
Implementers should be aware that a token introspection request lets the AS know when the client (and potentially the user) is accessing the RS, which is also an indication of when the user is using the client. If this implication is not acceptable, implementers MUST use other means to relay access token data, for example, by directly transferring the data needed by the RS within the access token.
実装者は、トークンイントロスペクション要求により、クライアント（および潜在的にユーザー）がRSにアクセスしていることをAS ASを知ることができることに注意する必要があります。これは、ユーザーがクライアントを使用していることも示すものです。If this implication is not acceptable, implementers MUST use other means to relay access token data, for example, by directly transferring the data needed by the RS within the access token.
The following client metadata definitions have been registered in the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]:
次のクライアントメタデータ定義は、[RFC7591]によって確立されたIANA "OAuth Dynamic Client Registration Metadata" Registry [iana.oauth.parameters]に登録されています。
Client Metadata Name:
クライアントメタデータ名：
introspection_signed_response_alg
introspection_signed_response_alg
Client Metadata Description:
クライアントメタデータの説明：
String value indicating the client's desired introspection response signing algorithm
クライアントが望むイントロスペクション応答を示す文字列値署名アルゴリズム
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 6 of RFC 9701
RFC 9701のセクション6
Client Metadata Name:
クライアントメタデータ名：
introspection_encrypted_response_alg
introspection_encrypted_response_alg
Client Metadata Description:
クライアントメタデータの説明：
String value specifying the desired introspection response content key encryption algorithm (alg value)
文字列値目的のイントロスペクション応答コンテンツキー暗号化アルゴリズム（alg値）を指定する
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 6 of RFC 9701
RFC 9701のセクション6
Client Metadata Name:
クライアントメタデータ名：
introspection_encrypted_response_enc
Introspection_encrypted_response_enc
Client Metadata Description:
クライアントメタデータの説明：
String value specifying the desired introspection response content encryption algorithm (enc value)
文字列値目的のイントロスペクション応答コンテンツ暗号化アルゴリズム（enc値）を指定する
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 6 of RFC 9701
RFC 9701のセクション6
The following values have been registered 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:
メタデータ名：
introspection_signing_alg_values_supported
introspection_singe_alg_values_supported
Metadata Description:
メタデータの説明：
JSON array containing a list of algorithms supported by the authorization server for introspection response signing
イントロスペクション応答のために承認サーバーによってサポートされているアルゴリズムのリストを含むJSONアレイ
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 7 of RFC 9701
RFC 9701のセクション7
Metadata Name:
メタデータ名：
introspection_encryption_alg_values_supported
Introspection_encryption_alg_values_supported
Metadata Description:
メタデータの説明：
JSON array containing a list of algorithms supported by the authorization server for introspection response content key encryption (alg value)
イントロスペクション応答コンテンツの認証サーバーによってサポートされているアルゴリズムのリストを含むJSONアレイキー暗号化（ALG値）
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 7 of RFC 9701
RFC 9701のセクション7
Metadata Name:
メタデータ名：
introspection_encryption_enc_values_supported
Introspection_encryption_enc_values_supported
Metadata Description:
メタデータの説明：
JSON array containing a list of algorithms supported by the authorization server for introspection response content encryption (enc value)
イントロスペクション応答コンテンツ暗号化のために承認サーバーによってサポートされているアルゴリズムのリストを含むJSONアレイ（ENC値）
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 7 of RFC 9701
RFC 9701のセクション7
The "application/token-introspection+jwt" media type has been registered in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838]. It can be used to indicate that the content is a token introspection response in JWT format.
[RFC6838]で説明されている方法で、「Application/Token-intropection+JWT」メディアタイプが「メディアタイプ」レジストリ[iana.mediatypes]に登録されています。コンテンツがJWT形式でのトークンイントロスペクション応答であることを示すために使用できます。
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
token-introspection+jwt
トークンイントレッジ+jwt
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
binary. A token introspection response is a JWT; JWT values are encoded as a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters.
バイナリ。トークンイントロスペクション反応はJWTです。JWT値は、一連のbase64urlエンコード値（後続の '='文字が削除されている）としてエンコードされ、その一部は空の文字列であり、ピリオド（ '。'）文字で区切られている場合があります。
Security considerations:
セキュリティ上の考慮事項：
See Section 8 of RFC 9701
RFC 9701のセクション8を参照してください
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
Section 4 of RFC 9701
RFC 9701のセクション4
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Applications that produce and consume OAuth Token Introspection Responses in JWT format
JWT形式でOAuthトークンイントロスペクション応答を生成および消費するアプリケーション
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
N/A
n/a
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Torsten Lodderstedt (torsten@lodderstedt.net)
Torsten Lodderstedt（torsten@lodderstedt.net）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なし
Author:
著者：
Torsten Lodderstedt (torsten@lodderstedt.net)
Torsten Lodderstedt（torsten@lodderstedt.net）
Change controller:
Change Controller：
IETF
IETF
The "token_introspection" claim has been registered in the "JSON Web Token (JWT)" registry [IANA.JWT] in the manner described in [RFC7519].
「token_intropection」クレームは、[RFC7519]で説明されている方法で「JSON Web Token（JWT）」レジストリ[IANA.JWT]に登録されています。
Claim Name:
クレーム名：
token_introspection
token_intropection
Claim Description:
クレームの説明：
Token introspection response
トークンイントロスペクション応答
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 5 of RFC 9701
RFC 9701のセクション5
[IANA.JWT] IANA, "JSON Web Token (JWT) Claims",
<https://www.iana.org/assignments/jwt>.
[IANA.MediaTypes]
IANA, "Media Types",
<http://www.iana.org/assignments/media-types>.
[IANA.OAuth.Token.Introspection]
IANA, "OAuth Token Introspection Response",
<https://www.iana.org/assignments/oauth-parameters>.
[OpenID.Registration]
Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
Dynamic Client Registration 1.0 incorporating errata set
1", November 2014, <https://openid.net/specs/openid-
connect-registration-1_0.html>.
[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>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
[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>.
[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>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"Best Current Practice for OAuth 2.0 Security", BCP 240,
RFC 9700, DOI 10.17487/RFC9700, January 2025,
<https://www.rfc-editor.org/info/rfc9700>.
[IANA.OAuth.Parameters]
IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>.
We would like to thank Petteri Stenius, Neil Madden, Filip Skokan, Tony Nadalin, Remco Schaar, Justin Richer, Takahiko Kawasaki, Benjamin Kaduk, Robert Wilton, and Roman Danyliw for their valuable feedback.
ペッテリ・ステニウス、ニール・マッデン、フィリップ・スコカン、トニー・ナダリン、レームコ・シャーアー、ジャスティン・リッチャー、川崎高子、ベンジャミン・カドゥク、ロバート・ウィルトン、ロマン・ダニリウの貴重なフィードバックに感謝します。
Torsten Lodderstedt (editor)
yes.com AG
Email: torsten@lodderstedt.net
Vladimir Dzhuvinov
Connect2id Ltd.
Email: vladimir@connect2id.com