Internet Engineering Task Force (IETF) M.B. Jones
Request for Comments: 9728 Self-Issued Consulting
Category: Standards Track P. Hunt
ISSN: 2070-1721 Independent Identity, Inc.
A. Parecki
Okta
April 2025
This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource.
この仕様では、OAUTH 2.0クライアントまたは承認サーバーがOAUTH 2.0保護されたリソースと対話するために必要な情報を取得するために使用できるメタデータ形式を定義します。
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/rfc9728.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9728で取得できます。
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
1.1. Requirements Notation and Conventions
1.2. Terminology
2. Protected Resource Metadata
2.1. Human-Readable Resource Metadata
2.2. Signed Protected Resource Metadata
3. Obtaining Protected Resource Metadata
3.1. Protected Resource Metadata Request
3.2. Protected Resource Metadata Response
3.3. Protected Resource Metadata Validation
4. Authorization Server Metadata
5. Use of WWW-Authenticate for Protected Resource Metadata
5.1. WWW-Authenticate Response
5.2. Changes to Resource Metadata
5.3. Client Identifier and Client Authentication
5.4. Compatibility with Other Authentication Methods
6. String Operations
7. Security Considerations
7.1. TLS Requirements
7.2. Scopes
7.3. Impersonation Attacks
7.4. Audience-Restricted Access Tokens
7.5. Publishing Metadata in a Standard Format
7.6. Authorization Servers
7.7. Server-Side Request Forgery (SSRF)
7.8. Phishing
7.9. Differences Between Unsigned and Signed Metadata
7.10. Metadata Caching
8. IANA Considerations
8.1. OAuth Protected Resource Metadata Registry
8.1.1. Registration Template
8.1.2. Initial Registry Contents
8.2. OAuth Authorization Server Metadata Registry
8.2.1. Registry Contents
8.3. Well-Known URIs Registry
8.3.1. Registry Contents
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
This specification defines a metadata format enabling OAuth 2.0 clients and authorization servers to obtain information needed to interact with an OAuth 2.0 protected resource. The structure and content of this specification are intentionally as parallel as possible to (1) "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591], which enables a client to provide metadata about itself to an OAuth 2.0 authorization server and (2) "OAuth 2.0 Authorization Server Metadata" [RFC8414], which enables a client to obtain metadata about an OAuth 2.0 authorization server.
この仕様では、OAUTH 2.0クライアントと承認サーバーがOAUTH 2.0保護されたリソースと対話するために必要な情報を取得できるメタデータ形式を定義します。この仕様の構造と内容は、（1）「OAUTH 2.0ダイナミッククライアント登録プロトコル」[RFC7591]と可能な限り並行して意図的に並行しています。これにより、クライアントはOAUTH 2.0認証サーバーにメタデータを提供できます。サーバー。
The means by which the client obtains the location of the protected resource is out of scope for this document. In some cases, the location may be manually configured into the client; for example, an email client could provide an interface for a user to enter the URL of their JSON Meta Application Protocol (JMAP) server [RFC8620]. In other cases, it may be dynamically discovered; for example, a user could enter their email address into an email client, the client could perform WebFinger discovery [RFC7033] (in a manner related to the description in Section 2 of [OpenID.Discovery]) to find the resource server, and the client could then fetch the resource server metadata to find the authorization server to use to obtain authorization to access the user's email.
クライアントが保護されたリソースの場所を取得する手段は、このドキュメントの範囲外です。場合によっては、場所をクライアントに手動で構成することができます。たとえば、電子メールクライアントは、ユーザーがJSONメタアプリケーションプロトコル（JMAP）サーバー[RFC8620]のURLを入力するインターフェイスを提供できます。他の場合には、動的に発見される場合があります。たとえば、ユーザーは電子メールアドレスを電子メールクライアントに入力できます。クライアントはWebfinger Discovery [RFC7033]（[openID.discovery]のセクション2の説明に関連する方法で）を実行してリソースサーバーを見つけます。クライアントは、ユーザーのメールにアクセスするための認証サーバーを見つけるためにリソースサーバーメタデータを取得できます。
The metadata for a protected resource is retrieved from a well-known location as a JSON [RFC8259] document, which declares information about its capabilities and, optionally, its relationships with other services. This process is described in Section 3.
保護されたリソースのメタデータは、JSON [RFC8259]ドキュメントとしてよく知られている場所から取得されます。これは、その機能、およびオプションで他のサービスとの関係に関する情報を宣言します。このプロセスについては、セクション3で説明します。
This metadata can be communicated either in a self-asserted fashion or as a set of signed metadata values represented as claims in a JSON Web Token (JWT) [JWT]. In the JWT case, the issuer is vouching for the validity of the data about the protected resource. This is analogous to the role that the software statement plays in OAuth Dynamic Client Registration [RFC7591].
このメタデータは、自己容疑で、またはJSON Webトークン（JWT）[JWT]のクレームとして表される署名されたメタデータ値のセットとして伝えることができます。JWTの場合、発行者は保護されたリソースに関するデータの有効性を保証しています。これは、ソフトウェアステートメントがOAuth Dynamic Client登録で果たす役割に類似しています[RFC7591]。
Each protected resource publishing metadata about itself makes its own metadata document available at a well-known location deterministically derived from the protected resource's URL, even when the resource server implements multiple protected resources. This prevents attackers from publishing metadata that supposedly describes the protected resource but that is not actually authoritative for the protected resource, as described in Section 7.3.
各保護されたリソース出版メタデータ自体が、リソースサーバーが複数の保護されたリソースを実装している場合でも、保護されたリソースのURLから決定的に導出された有名な場所で独自のメタデータドキュメントを利用できます。これにより、攻撃者は保護されたリソースを記述していると思われるメタデータを公開することを防ぎますが、セクション7.3で説明されているように、保護されたリソースに対して実際には権威がありません。
Section 2 defines metadata parameters that a protected resource can publish, which includes things like which scopes are supported, how a client can present an access token, and more. These values, such as the jwks_uri (see Section 2), may be used with other specifications; for example, the public keys published in the jwks_uri can be used to verify the signed resource responses, as described in [FAPI.MessageSigning].
セクション2では、保護されたリソースが公開できるメタデータパラメーターを定義します。これには、スコープがサポートされているもの、クライアントがアクセストークンを提示する方法などが含まれます。JWKS_URI（セクション2を参照）などのこれらの値は、他の仕様で使用できます。たとえば、JWKS_URIで公開されているパブリックキーを使用して、[fapi.messageing]で説明されているように、署名されたリソース応答を検証できます。
Section 5 describes the use of WWW-Authenticate by protected resources to dynamically inform clients of the URL of their protected resource metadata. This use of WWW-Authenticate can indicate that the protected resource metadata may have changed.
セクション5では、保護されたリソースによるwww-authenticateの使用について、保護されたリソースメタデータのURLをクライアントに動的に通知します。www-authenticateのこの使用は、保護されたリソースメタデータが変更された可能性があることを示すことができます。
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] で説明されているように解釈されます。
All applications of JSON Web Signature (JWS) data structures [JWS] and JSON Web Encryption (JWE) data structures [JWE] as discussed in this specification utilize the JWS Compact Serialization or the JWE Compact Serialization; the JWS JSON Serialization and the JWE JSON Serialization are not used. Choosing a single serialization is intended to facilitate interoperability.
JSON Web Signature（JWS）データ構造[JWS]およびJSON Web暗号化（JWE）データ構造[JWE]のすべてのアプリケーションは、JWSコンパクトシリアル化またはJWEコンパクトシリアル化を利用しています。JWS JSONシリアル化とJWE JSONシリアル化は使用されていません。単一のシリアル化を選択することは、相互運用性を促進することを目的としています。
This specification uses the terms "access token", "authorization code", "authorization server", "client", "client authentication", "client identifier", "protected resource", and "resource server" defined by OAuth 2.0 [RFC6749], and the terms "Claim Name" and "JSON Web Token (JWT)" defined by "JSON Web Token (JWT)" [JWT].
この仕様では、「アクセストークン」、「認証コード」、「認証サーバー」、「クライアント」、「クライアント認証」、「クライアント識別子」、「保護されたリソース」、および「RFC6749」[RFC6749]、および「クレーム名」と「JSON Web Token（JWT）」で定義された「リソースサーバー」という用語を使用します。
This specification defines the following term:
この仕様は次の用語を定義します。
Resource Identifier:
リソース識別子：
The protected resource's resource identifier, which is a URL that uses the https scheme and has no fragment component. As specified in Section 2 of [RFC8707], it also SHOULD NOT include a query component, but it is recognized that there are cases that make a query component a useful and necessary part of a resource identifier. Protected resource metadata is published at a .well-known location [RFC8615] derived from this resource identifier, as described in Section 3.
保護されたリソースのリソース識別子は、HTTPSスキームを使用し、フラグメントコンポーネントを持たないURLです。[RFC8707]のセクション2で指定されているように、クエリコンポーネントも含めるべきではありませんが、クエリコンポーネントをリソース識別子の有用かつ必要な部分にするケースがあることが認識されています。保護されたリソースメタデータは、セクション3で説明されているように、このリソース識別子から派生した.well-known Location [RFC8615]で公開されています。
Protected resources can have metadata describing their configuration. The following protected resource metadata parameters are used by this specification and are registered in the "OAuth Protected Resource Metadata" registry established in Section 8.1:
保護されたリソースには、構成を説明するメタデータがあります。次の保護されたリソースメタデータパラメーターは、この仕様で使用され、セクション8.1で確立された「OAuth保護されたリソースメタデータ」レジストリに登録されています。
resource
リソース
REQUIRED. The protected resource's resource identifier, as defined in Section 1.2.
必須。セクション1.2で定義されているように、保護されたリソースのリソース識別子。
authorization_servers
authorization_servers
OPTIONAL. JSON array containing a list of OAuth authorization server issuer identifiers, as defined in [RFC8414], for authorization servers that can be used with this protected resource. Protected resources MAY choose not to advertise some supported authorization servers even when this parameter is used. In some use cases, the set of authorization servers will not be enumerable, in which case this metadata parameter would not be used.
オプション。[RFC8414]で定義されているOAuth Authorization Server発行者識別子のリストを含むJSONアレイは、この保護されたリソースで使用できる承認サーバーのために。保護されたリソースは、このパラメーターが使用されている場合でも、いくつかのサポートされている承認サーバーを宣伝しないことを選択できます。一部のユースケースでは、一連の承認サーバーは列挙できません。その場合、このメタデータパラメーターは使用されません。
jwks_uri
jwks_uri
OPTIONAL. URL of the protected resource's JSON Web Key (JWK) Set [JWK] document. This contains public keys belonging to the protected resource, such as signing key(s) that the resource server uses to sign resource responses. This URL MUST use the https scheme. When both signing and encryption keys are made available, a use (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage.
オプション。保護されたリソースのJSON Webキー（JWK）セット[JWK]ドキュメントのURL。これには、リソースサーバーがリソース応答に署名するために使用する署名キーなど、保護されたリソースに属するパブリックキーが含まれています。このURLはHTTPSスキームを使用する必要があります。署名キーと暗号化キーの両方が利用可能になると、参照されたJWKセットのすべてのキーに使用（公開キーの使用）パラメーター値が必要です。
scopes_supported
scopes_supported
RECOMMENDED. JSON array containing a list of scope values, as defined in OAuth 2.0 [RFC6749], that are used in authorization requests to request access to this protected resource. Protected resources MAY choose not to advertise some scope values supported even when this parameter is used.
推奨。OAUTH 2.0 [RFC6749]で定義されているスコープ値のリストを含むJSONアレイは、この保護されたリソースへのアクセスを要求する認定要求で使用されます。保護されたリソースは、このパラメーターが使用されている場合でも、サポートされているスコープ値を宣伝しないことを選択できます。
bearer_methods_supported
Bearer_methods_supported
OPTIONAL. JSON array containing a list of the supported methods of sending an OAuth 2.0 bearer token [RFC6750] to the protected resource. Defined values are ["header", "body", "query"], corresponding to Sections 2.1, 2.2, and 2.3 of [RFC6750]. The empty array [] can be used to indicate that no bearer methods are supported. If this entry is omitted, no default bearer methods supported are implied, nor does its absence indicate that they are not supported.
オプション。OAUTH 2.0 BEARERトークン[RFC6750]を保護されたリソースに送信するサポートされている方法のリストを含むJSONアレイ。定義された値は["" header "、" body "、" query "]で、[RFC6750]のセクション2.1、2.2、および2.3に対応しています。空の配列[]を使用して、ベアラーの方法がサポートされていないことを示すことができます。このエントリが省略されている場合、サポートされているデフォルトのベアラーメソッドは暗示されておらず、その不在は、それらがサポートされていないことを示しません。
resource_signing_alg_values_supported
resource_singe_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS [JWS] signing algorithms (alg values) [JWA] supported by the protected resource for signing resource responses, for instance, as described in [FAPI.MessageSigning]. No default algorithms are implied if this entry is omitted. The value none MUST NOT be used.
オプション。JWS [JWS]署名アルゴリズム（alg値）[JWA]のリストを含むJSONアレイ[JWA]は、[fapi.messageing]で説明されているように、リソース応答などのリソース応答に署名するためにサポートされています。このエントリが省略されている場合、デフォルトのアルゴリズムは暗示されていません。値は使用してはなりません。
resource_name
resource_name
Human-readable name of the protected resource intended for display to the end user. It is RECOMMENDED that protected resource metadata include this field. The value of this field MAY be internationalized, as described in Section 2.1.
エンドユーザーへの表示を目的とした保護されたリソースの人間読み取り可能な名前。保護されたリソースメタデータにはこのフィールドを含めることをお勧めします。セクション2.1で説明されているように、このフィールドの値は国際化される場合があります。
resource_documentation
resource_documentation
OPTIONAL. URL of a page containing human-readable information that developers might want or need to know when using the protected resource. The value of this field MAY be internationalized, as described in Section 2.1.
オプション。開発者が保護されたリソースを使用する際に必要な、または知る必要があるかもしれない人間の読み取り可能な情報を含むページのURL。セクション2.1で説明されているように、このフィールドの値は国際化される場合があります。
resource_policy_uri
resource_policy_uri
OPTIONAL. URL of a page containing human-readable information about the protected resource's requirements on how the client can use the data provided by the protected resource. The value of this field MAY be internationalized, as described in Section 2.1.
オプション。保護されたリソースの要件に関するヒューマン読み取り可能な情報を含むページのURLは、保護されたリソースによって提供されるデータをクライアントがどのように使用できるかに関する要件を含みます。セクション2.1で説明されているように、このフィールドの値は国際化される場合があります。
resource_tos_uri
resource_tos_uri
OPTIONAL. URL of a page containing human-readable information about the protected resource's terms of service. The value of this field MAY be internationalized, as described in Section 2.1.
オプション。保護されたリソースのサービス利用規約に関する人間が読みやすい情報を含むページのURL。セクション2.1で説明されているように、このフィールドの値は国際化される場合があります。
tls_client_certificate_bound_access_tokens
tls_client_certificate_bound_access_tokens
OPTIONAL. Boolean value indicating protected resource support for mutual-TLS client certificate-bound access tokens [RFC8705]. If omitted, the default value is false.
オプション。相互TLSクライアントの証明書バウンドアクセストークンの保護されたリソースサポートを示すブール値[RFC8705]。省略した場合、デフォルト値はfalseです。
authorization_details_types_supported
authorization_details_types_supported
OPTIONAL. JSON array containing a list of the authorization details type values supported by the resource server when the authorization_details request parameter [RFC9396] is used.
オプション。Authorization_Detailsリクエストパラメーター[RFC9396]が使用されたときに、リソースサーバーでサポートされている承認詳細のリストを含むJSONアレイが使用されます。
dpop_signing_alg_values_supported
dpop_singe_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS alg values (from the "JSON Web Signature and Encryption Algorithms" registry [IANA.JOSE]) supported by the resource server for validating Demonstrating Proof of Possession (DPoP) proof JWTs [RFC9449].
オプション。JWSアルグ値のリストを含むJSONアレイ（「JSON Web署名および暗号化アルゴリズム」レジストリ[IANA.JOSE]から）リソースサーバーがサポートしています。
dpop_bound_access_tokens_required
dpop_bound_access_tokens_required
OPTIONAL. Boolean value specifying whether the protected resource always requires the use of DPoP-bound access tokens [RFC9449]. If omitted, the default value is false.
オプション。保護されたリソースが常にDPOPバウンドアクセストークンの使用を必要とするかどうかを指定するブール値[RFC9449]。省略した場合、デフォルト値はfalseです。
Additional protected resource metadata parameters MAY also be used.
追加の保護されたリソースメタデータパラメーターも使用できます。
Human-readable resource metadata values and resource metadata values that reference human-readable content MAY be represented in multiple languages and scripts. For example, the values of fields such as resource_name, resource_documentation, resource_tos_uri, and resource_policy_uri might have multiple locale-specific metadata values to facilitate use in different locations.
人間の読み取り可能なリソースメタデータ値とリソースメタデータ値は、人間の読み取り可能なコンテンツを参照するものを複数の言語とスクリプトで表すことができます。たとえば、Resource_Name、Resource_Documentation、Resource_Tos_uri、Resource_Policy_uriなどのフィールドの値は、異なる場所での使用を促進するために複数のロケール固有のメタデータ値を持つ場合があります。
To specify the languages and scripts, language tags [BCP47] are added to resource metadata parameter names, delimited by a # character. Since member names as discussed in JSON [RFC8259] are case sensitive, it is RECOMMENDED that language tag values used in Claim Names be spelled using the character case with which they are registered in the "Language Subtag Registry" [IANA.Language]. In particular, normally, language names are spelled with lowercase characters, region names are spelled with uppercase characters, and languages are spelled with mixed-case characters. However, since language tag values are case insensitive per [BCP47], implementations SHOULD interpret the language tag values supplied in a case-insensitive manner. Per the recommendations in [BCP47], language tag values used in metadata parameter names should only be as specific as is necessary. For instance, using fr might be sufficient in many contexts, rather than fr-CA or fr-FR.
言語とスクリプトを指定するために、言語タグ[BCP47]は、＃文字によって区切られたリソースメタデータパラメーター名に追加されます。JSON [RFC8259]で説明されているメンバー名はケースに敏感であるため、クレーム名で使用される言語タグ値は、「言語サブタグレジストリ」[iana.language]に登録されている文字ケースを使用して綴ることをお勧めします。特に、通常、言語名は小文字で綴られ、地域名は大文字で綴られ、言語は混合ケース文字で綴られます。ただし、言語タグの値は[BCP47]ごとに症例不敏感であるため、実装はケース非感受性で提供される言語タグ値を解釈する必要があります。[BCP47]の推奨事項によると、メタデータパラメーター名で使用される言語タグ値は、必要な限り具体的でなければなりません。たとえば、FRを使用することは、FR-CAまたはFR-FRではなく、多くのコンテキストで十分かもしれません。
For example, a resource could represent its name in English as "resource_name#en": "My Resource" and its name in Italian as "resource_name#it": "La mia bella risorsa" within its metadata. Any or all of these names MAY be displayed to the end user, choosing which names to display based on system configuration, user preferences, or other factors.
たとえば、リソースは英語の名前を「Resource_Name＃EN」：「My Resource」として、イタリア語での名前を「Resource_Name＃IT」：「La Mia Bella Risorsa」としてメタデータ内に表すことができます。これらの名前のいずれかまたはすべてがエンドユーザーに表示される場合があり、システム構成、ユーザー設定、またはその他の要因に基づいて表示する名前を選択します。
If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as is wherever it is presented in a user interface. To facilitate interoperability, it is RECOMMENDED that each kind of human-readable metadata provided include an instance of its metadata parameter without any language tags in addition to any language-specific parameters, and it is RECOMMENDED that any human-readable fields sent without language tags contain values suitable for display on a wide variety of systems.
人間の読み取り可能なフィールドが言語タグなしで送信される場合、それを使用する当事者は、文字列値の言語、文字セット、またはスクリプトについて仮定を立ててはなりません。また、文字列値は、ユーザーインターフェイスのどこにいても使用する必要があります。相互運用性を容易にするために、提供される人間が読みやすいメタデータの各種類には、言語固有のパラメーターに加えて言語タグのないメタデータパラメーターのインスタンスを含めることをお勧めします。
In addition to JSON elements, metadata values MAY also be provided as a signed_metadata value, which is a JSON Web Token (JWT) [JWT] that asserts metadata values about the protected resource as a bundle. A set of metadata parameters that can be used in signed metadata as claims are defined in Section 2. The signed metadata MUST be digitally signed or MACed (protected with a Message Authentication Code) using a JSON Web Signature (JWS) [JWS] and MUST contain an iss (issuer) claim denoting the party attesting to the claims in the signed metadata. Consumers of the metadata MAY ignore the signed metadata if they do not support this feature. If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.
JSON要素に加えて、メタデータ値は、保護されたリソースに関するメタデータ値をバンドルとして主張するJSON Webトークン（JWT）[JWT]であるSigned_Metadata値として提供される場合があります。クレームとして署名されたメタデータで使用できる一連のメタデータパラメーターは、セクション2で定義されています。署名されたメタデータは、JSON Web署名（JWS）[JWS]を使用してデジタル署名またはマケッド（メッセージ認証コードで保護）を使用する必要があり、ISS（発行者）が含まれている必要があります。メタデータの消費者は、この機能をサポートしていない場合、署名されたメタデータを無視する場合があります。メタデータの消費者が署名されたメタデータをサポートする場合、署名されたメタデータで伝えられるメタデータ値は、プレーンJSON要素を使用して伝えられる対応する値よりも優先される必要があります。
Signed metadata is included in the protected resource metadata JSON object using this OPTIONAL metadata parameter:
署名されたメタデータは、このオプションのメタデータパラメーターを使用して、保護されたリソースメタデータJSONオブジェクトに含まれています。
signed_metadata
signed_metadata
A JWT containing metadata parameters about the protected resource as claims. This is a string value consisting of the entire signed JWT. A signed_metadata parameter SHOULD NOT appear as a claim in the JWT; it is RECOMMENDED to reject any metadata in which this occurs.
保護されたリソースに関するメタデータパラメーターをクレームとして含むJWT。これは、署名されたJWT全体で構成される文字列値です。signed_metadataパラメーターは、JWTのクレームとして表示されてはなりません。これが発生するメタデータを拒否することをお勧めします。
Protected resources supporting metadata MUST make a JSON document containing metadata as specified in Section 2 available at a URL formed by inserting a well-known URI string into the protected resource's resource identifier between the host component and the path and/or query components, if any. By default, the well-known URI string used is /.well-known/oauth-protected-resource. The syntax and semantics of .well-known are defined in [RFC8615]. The well-known URI path suffix used MUST be registered in the "Well-Known URIs" registry [IANA.well-known]. Examples of this construction can be found in Section 3.1.
メタデータをサポートする保護されたリソースは、有名なURI文字列をホストコンポーネントとパスおよび/またはクエリコンポーネントとの間の保護されたリソースのリソース識別子に挿入することによって形成されたURLで利用可能なセクション2で指定されたメタデータを含むJSONドキュメントを作成する必要があります。デフォルトでは、使用されるよく知られているURI文字列は /.Well-Known /Oauth-Protected-Resourceです。.well-knowsの構文とセマンティクスは[RFC8615]で定義されています。使用されるよく知られているURIパスの接尾辞は、「有名なURIS」レジストリ[iana.well-known]に登録する必要があります。この構造の例は、セクション3.1にあります。
The term "application", as used below (and as used in [RFC8414]), encompasses all the components used to accomplish the task for the use case. That can include OAuth clients, authorization servers, protected resources, and non-OAuth components, inclusive of the code running in each of them. Applications are built to solve particular problems and may utilize many components and services.
以下で使用される（および[RFC8414]で使用される）「アプリケーション」という用語は、ユースケースのタスクを達成するために使用されるすべてのコンポーネントを含みます。これには、それぞれで実行されているコードを含む、OAuthクライアント、認証サーバー、保護されたリソース、および非OAUTHコンポーネントが含まれます。アプリケーションは特定の問題を解決するために構築されており、多くのコンポーネントとサービスを利用する場合があります。
Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well-known URI path suffixes for publishing protected resource metadata used by those applications. For instance, if the Example application uses an OAuth protected resource in an Example-specific way and there are Example-specific metadata values that it needs to publish, then it might register and use the example-protected-resource URI path suffix and publish the metadata document at the URL formed by inserting /.well-known/example-protected-resource between the host and path and/or query components of the protected resource's resource identifier. Alternatively, many such applications will use the default well-known URI string /.well-known/oauth-protected-resource, which is the right choice for general-purpose OAuth protected resources, and not register an application-specific one.
OAUTH保護されたリソースをアプリケーション固有の方法で使用するさまざまなアプリケーションは、これらのアプリケーションで使用される保護されたリソースメタデータを公開するためのさまざまな有名なURIパスサフィックスを定義および登録することができます。たとえば、サンプルアプリケーションが例固有の方法でOAuth保護されたリソースを使用し、公開する必要がある例固有のメタデータ値がある場合、URIパスのサフィックスを登録および使用し、/.well-konded-completected-resurtected-resourted-resurtected-resourents forth compentの挿入によって形成されたURLでメタデータドキュメントを公開する場合があります。識別子。あるいは、そのようなアプリケーションの多くは、デフォルトのよく知られているURI String /.Well-Known/Oauth-Protected-Resourceを使用します。
An OAuth 2.0 application using this specification MUST specify what well-known URI suffix it will use for this purpose. The same protected resource MAY choose to publish its metadata at multiple well-known locations derived from its resource identifier -- for example, publishing metadata at both /.well-known/example-protected-resource and /.well-known/oauth-protected-resource.
この仕様を使用したOAUTH 2.0アプリケーションは、この目的に使用する有名なURIサフィックスを指定する必要があります。同じ保護されたリソースは、そのリソース識別子から派生した複数の有名な場所でそのメタデータを公開することを選択できます。たとえば、メタデータを /.Well-Nownexample-Protected-Resourceと /.Well-Nownote/Oauth-Protected-Resourceの両方で公開します。
A protected resource metadata document MUST be queried using an HTTP GET request at the previously specified URL.
保護されたリソースメタデータドキュメントは、以前に指定されたURLでHTTP GETリクエストを使用して照会する必要があります。
The consumer of the metadata would make the following request when the resource identifier is https://resource.example.com and the well-known URI path suffix is oauth-protected-resource to obtain the metadata, since the resource identifier contains no path component:
メタデータの消費者は、リソース識別子がhttps://resource.example.comであり、有名なURIパスの接尾辞がメタデータを取得するためのoauth保護対象である場合に次の要求を行います。リソース識別子にはパスコンポーネントが含まれていないため、
GET /.well-known/oauth-protected-resource HTTP/1.1
Host: resource.example.com
If the resource identifier value contains a path or query component, any terminating slash (/) following the host component MUST be removed before inserting /.well-known/ and the well-known URI path suffix between the host component and the path and/or query components. The consumer of the metadata would make the following request when the resource identifier is https://resource.example.com/ resource1 and the well-known URI path suffix is oauth-protected-resource to obtain the metadata, since the resource identifier contains a path component:
リソース識別子値にパスまたはクエリコンポーネントが含まれている場合、/.Well-Nownd/とホストコンポーネントとパスおよび/またはクエリコンポーネントの間の有名なURIパスの接尾辞を挿入する前に、ホストコンポーネントに続く終端スラッシュ（/）を削除する必要があります。メタデータの消費者は、リソース識別子がhttps://resource.example.com/ resource1であり、有名なURIパスの接尾辞が、リソース識別子にパスコンポーネントが含まれているため、メタデータを取得するためのOAuthで保護されたリソースである場合、次の要求を行います。
GET /.well-known/oauth-protected-resource/resource1 HTTP/1.1
Host: resource.example.com
Using path components enables supporting multiple resources per host. This is required in some multi-tenant hosting configurations. This use of .well-known is for supporting multiple resources per host; unlike its use in [RFC8615], it does not provide general information about the host.
パスコンポーネントを使用すると、ホストごとに複数のリソースをサポートできます。これは、一部のマルチテナントホスティング構成で必要です。.well-knownのこの使用は、ホストあたりの複数のリソースをサポートするためのものです。[RFC8615]での使用とは異なり、ホストに関する一般的な情報は提供されません。
The response is a set of metadata parameters about the protected resource's configuration. A successful response MUST use the 200 OK HTTP status code and return a JSON object using the application/json content type that contains a set of metadata parameters as its members that are a subset of the metadata parameters defined in Section 2. Additional metadata parameters MAY be defined and used; any metadata parameters that are not understood MUST be ignored.
応答は、保護されたリソースの構成に関する一連のメタデータパラメーターです。成功した応答は、200 OK HTTPステータスコードを使用し、セクション2で定義されたメタデータパラメーターのサブセットであるメタデータパラメーターのセットを含むアプリケーション/JSONコンテンツタイプを使用してJSONオブジェクトを返す必要があります。追加のメタデータパラメーターを定義および使用できます。理解されていないメタデータパラメーターは無視する必要があります。
Parameters with multiple values are represented as JSON arrays. Parameters with zero values MUST be omitted from the response.
複数の値を持つパラメーターは、JSONアレイとして表されます。ゼロ値のパラメーターは、応答から省略する必要があります。
An error response uses the applicable HTTP status code value.
エラー応答では、該当するHTTPステータスコード値を使用します。
The following is a non-normative example response:
以下は、非規範的な例の応答です。
HTTP/1.1 200 OK
Content-Type: application/json
{
"resource":
"https://resource.example.com",
"authorization_servers":
["https://as1.example.com",
"https://as2.example.net"],
"bearer_methods_supported":
["header", "body"],
"scopes_supported":
["profile", "email", "phone"],
"resource_documentation":
"https://resource.example.com/resource_documentation.html"
}
The resource value returned MUST be identical to the protected resource's resource identifier value into which the well-known URI path suffix was inserted to create the URL used to retrieve the metadata. If these values are not identical, the data contained in the response MUST NOT be used.
返されるリソース値は、保護されたリソースのリソース識別子値と同じでなければなりません。この値は、よく知られているURIパスサフィックスが挿入され、メタデータを取得するために使用されるURLを作成します。これらの値が同一でない場合、応答に含まれるデータを使用してはなりません。
If the protected resource metadata was retrieved from a URL returned by the protected resource via the WWW-Authenticate resource_metadata parameter, then the resource value returned MUST be identical to the URL that the client used to make the request to the resource server. If these values are not identical, the data contained in the response MUST NOT be used.
保護されたリソースメタデータが、www-authenticate resource_metadataパラメーターを介して保護されたリソースによって返されたURLから取得された場合、返されるリソース値は、クライアントがリソースサーバーにリクエストするために使用したURLと同一でなければなりません。これらの値が同一でない場合、応答に含まれるデータを使用してはなりません。
These validation actions can thwart impersonation attacks, as described in Section 7.3.
これらの検証アクションは、セクション7.3で説明されているように、抑制攻撃を妨げる可能性があります。
The recipient MUST validate that any signed metadata was signed by a key belonging to the issuer and that the signature is valid. If the signature does not validate or the issuer is not trusted, the recipient SHOULD treat this as an error condition.
受信者は、署名されたメタデータが発行者に属する鍵によって署名され、署名が有効であることを検証する必要があります。署名が検証されない場合、または発行者が信頼されていない場合、受信者はこれをエラー条件として扱う必要があります。
To support use cases in which the set of legitimate protected resources to use with the authorization server is enumerable, this specification defines the authorization server metadata parameter protected_resources, which enables the authorization server to explicitly list the protected resources. Note that if the set of legitimate authorization servers to use with a protected resource is also enumerable, lists in the authorization server metadata and protected resource metadata should be cross-checked against one another for consistency when these lists are used by the application profile.
承認サーバーで使用する合法的な保護されたリソースのセットが列挙可能であるユースケースをサポートするために、この仕様はAuthorization Server Metadata Parameter Protected_Resourcesを定義します。これにより、認証サーバーは保護されたリソースを明示的にリストできます。保護されたリソースで使用する合法的な認証サーバーのセットも列挙可能である場合、承認サーバーメタデータと保護されたリソースメタデータのリストは、これらのリストをアプリケーションプロファイルで使用する場合、一貫性を互いにクロスチェックする必要があることに注意してください。
The following authorization server metadata parameter is defined by this specification and is registered in the "OAuth Authorization Server Metadata" registry established in "OAuth 2.0 Authorization Server Metadata" [RFC8414].
次のAuthorization Serverメタデータパラメーターは、この仕様によって定義され、「OAUTH 2.0 Authorization Server Metadata」[RFC8414]に確立された「OAuth Authorization Server Metadata」レジストリに登録されています。
protected_resources
protected_resources
OPTIONAL. JSON array containing a list of resource identifiers for OAuth protected resources that can be used with this authorization server. Authorization servers MAY choose not to advertise some supported protected resources even when this parameter is used. In some use cases, the set of protected resources will not be enumerable, in which case this metadata parameter will not be present.
オプション。この承認サーバーで使用できるOAUTH保護リソースのリソース識別子のリストを含むJSONアレイ。承認サーバーは、このパラメーターが使用されている場合でも、サポートされている保護されたリソースを宣伝しないことを選択できます。一部のユースケースでは、保護されたリソースのセットは列挙できません。その場合、このメタデータパラメーターは存在しません。
A protected resource MAY use the WWW-Authenticate HTTP response header field, as discussed in [RFC9110], to return a URL to its protected resource metadata to the client. The client can then retrieve protected resource metadata as described in Section 3. The client might then, for instance, determine what authorization server to use for the resource based on protected resource metadata retrieved.
保護されたリソースは、[RFC9110]で説明されているように、www-authenticate HTTP応答ヘッダーフィールドを使用して、保護されたリソースメタデータにURLをクライアントに返すことができます。クライアントは、セクション3で説明されているように、保護されたリソースメタデータを取得できます。たとえば、クライアントは、保護されたリソースメタデータを取得したリソースに使用する認証サーバーを決定する場合があります。
A typical end-to-end flow doing so is as follows. Note that while this example uses the OAuth 2.0 authorization code flow, a similar sequence could also be implemented with any other OAuth flow.
そうする典型的なエンドツーエンドのフローは次のとおりです。この例ではOAuth 2.0認証コードフローを使用しているが、同様のシーケンスも他のOAuthフローで実装できることに注意してください。
+----------+ +----------+ +---------------+
| Client | | Resource | | Authorization |
| | | Server | | Server |
+----+-----+ +----+-----+ +-------+-------+
| | |
| 1. Resource Request | |
| ----------------------> | |
| Without Access Token | |
| | |
| | |
| 2. WWW-Authenticate | |
| <---------------------- | |
| | |
| | |
| 3. Fetch RS Metadata | |
| ----------------------> | |
| | |
| | |
| 4. RS Metadata Response | |
| <---------------------- | |
| | |
+---------+---------------+ | |
| 5. Validate RS Metadata | | |
| Build AS Metadata URL | | |
+---------+---------------+ | |
| | |
| 6. Fetch AS Metadata | |
| ------------------------+----------------> |
| | |
| | |
| 7. AS Metadata Response | |
| <-----------------------+----------------- |
| | |
+-+-------------------------+------------------+-+
| 8-9. OAuth Authorization Code Flow |
| Client Obtains Access Token |
+-+-------------------------+------------------+-+
| | |
| 10. Resource Request | |
| ----------------------> | |
| With Access Token | |
| | |
| | |
| 11. Resource Response | |
| <---------------------- | |
| | |
+----+-----+ +----+-----+ +-------+-------+
| Client | | Resource | | Authorization |
| | | Server | | Server |
+----------+ +----------+ +---------------+
Figure 1: Sequence Diagram
図1：シーケンス図
1. The client makes a request to a protected resource without presenting an access token.
1. クライアントは、アクセストークンを提示することなく、保護されたリソースにリクエストを行います。
2. The resource server responds with a WWW-Authenticate header including the URL of the protected resource metadata.
2. リソースサーバーは、保護されたリソースメタデータのURLを含むwww-authenticateヘッダーで応答します。
3. The client fetches the protected resource metadata from this URL.
3. クライアントは、このURLから保護されたリソースメタデータを取得します。
4. The resource server responds with the protected resource metadata according to Section 3.2.
4. リソースサーバーは、セクション3.2に従って、保護されたリソースメタデータで応答します。
5. The client validates the protected resource metadata, as described in Section 3.3, and builds the authorization server metadata URL from an issuer identifier in the resource metadata according to [RFC8414].
5. クライアントは、セクション3.3で説明されているように、保護されたリソースメタデータを検証し、[RFC8414]に従ってリソースメタデータの発行者識別子から認証サーバーメタデータURLを構築します。
6. The client makes a request to fetch the authorization server metadata.
6. クライアントは、承認サーバーメタデータを取得するリクエストを行います。
7. The authorization server responds with the authorization server metadata document according to [RFC8414].
7. Authorization Serverは、[RFC8414]に従って、Authorization Serverメタデータドキュメントで応答します。
8. The client directs the user agent to the authorization server to begin the authorization flow.
8. クライアントは、ユーザーエージェントに承認サーバーに承認フローを開始するよう指示します。
9. The authorization exchange is completed and the authorization server returns an access token to the client.
9. 承認交換が完了し、承認サーバーはクライアントにアクセストークンを返します。
10. The client repeats the resource request from step 1, presenting the newly obtained access token.
10. クライアントは、手順1からリソース要求を繰り返し、新しく取得したアクセストークンを提示します。
11. The resource server returns the requested protected resource.
11. リソースサーバーは、要求された保護されたリソースを返します。
This specification introduces a new parameter in the WWW-Authenticate HTTP response header field to indicate the protected resource metadata URL:
この仕様では、保護されたリソースメタデータURLを示すために、www-authenticate http応答ヘッダーフィールドに新しいパラメーターを紹介します。
resource_metadata:
resource_metadata：
The URL of the protected resource metadata.
保護されたリソースメタデータのURL。
The response below is an example of a WWW-Authenticate header that includes the resource identifier.
以下の応答は、リソース識別子を含むwww-authenticateヘッダーの例です。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata=
"https://resource.example.com/.well-known/oauth-protected-resource"
The HTTP status code in the example response above is defined by [RFC6750].
上記のサンプル応答のHTTPステータスコードは、[RFC6750]で定義されています。
This parameter MAY also be used in WWW-Authenticate responses using authorization schemes other than "Bearer" [RFC6750], such as the DPoP scheme defined by [RFC9449].
このパラメーターは、[RFC9449]によって定義されたDPOPスキームなど、「Bearer」[RFC6750]以外の認証スキームを使用してwww-authenticate応答で使用することもできます。
The resource_metadata parameter MAY be combined with other parameters defined in other extensions, such as the max_age parameter defined by [RFC9470].
Resource_Metadataパラメーターは、[RFC9470]で定義されたMAX_AGEパラメーターなど、他の拡張機能で定義された他のパラメーターと組み合わせることができます。
At any point, for any reason determined by the resource server, the protected resource MAY respond with a new WWW-Authenticate challenge that includes a value for the protected resource metadata URL to indicate that its metadata may have changed. If the client receives such a WWW-Authenticate response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained, after validating them as described in Section 3.3. Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients.
いつでも、リソースサーバーによって決定された理由により、保護されたリソースは、保護されたリソースメタデータURLの値を含む新しいwww-authenticateチャレンジで、そのメタデータが変化した可能性があることを示すことができます。クライアントがそのようなwww-authenticate応答を受信した場合、セクション3.3で説明したように検証した後、更新された保護されたリソースメタデータを取得し、取得した新しいメタデータ値を使用する必要があります。とりわけ、これにより、リソースサーバーがクライアントとの他の調整なしに使用する承認サーバーを変更できます。
The way in which the client identifier is established at the authorization server is out of scope for this specification.
クライアント識別子が承認サーバーで確立される方法は、この仕様の範囲外です。
This specification is intended to be deployed in scenarios where the client has no prior knowledge about the resource server and where the resource server might or might not have prior knowledge about the client.
この仕様は、クライアントがリソースサーバーについて事前の知識を持たず、リソースサーバーがクライアントについて事前の知識を持っている場合としない場合があるシナリオに展開することを目的としています。
There are some existing methods by which an unrecognized client can make use of an authorization server, such as using Dynamic Client Registration [RFC7591] to register the client prior to initiating the authorization flow. Future OAuth extensions might define alternatives, such as using URLs to identify clients.
認識されていないクライアントが、承認フローを開始する前にクライアントを登録するためのダイナミッククライアント登録[RFC7591]を使用するなど、認定サーバーを使用できる既存の方法がいくつかあります。将来のOAUTH拡張機能は、URLを使用してクライアントを識別するなど、代替案を定義する場合があります。
Resource servers MAY return other WWW-Authenticate headers indicating various authentication schemes. This allows the resource server to support clients that may or may not implement this specification and allows clients to choose their preferred authentication scheme.
リソースサーバーは、さまざまな認証スキームを示す他のwww-authenticateヘッダーを返す場合があります。これにより、リソースサーバーは、この仕様を実装する、または実装できない場合があるクライアントをサポートし、クライアントが優先認証スキームを選択できるようになります。
Processing some OAuth 2.0 messages requires comparing values in the messages to known values. For example, the member names in the metadata response might be compared to specific member names such as resource. Comparing Unicode strings [UNICODE], however, has significant security implications.
一部のOAUTH 2.0メッセージを処理するには、メッセージ内の値を既知の値と比較する必要があります。たとえば、メタデータ応答のメンバー名は、リソースなどの特定のメンバー名と比較される場合があります。ただし、Unicode文字列[Unicode]を比較すると、セキュリティに大きな意味があります。
Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below:
したがって、JSON文字列と他のユニコード文字列の比較は、以下に指定するように実行する必要があります。
1. Remove any JSON-applied escaping to produce an array of Unicode code points.
1. JSONが適用した脱出を削除して、ユニコードコードポイントの配列を作成します。
2. Unicode Normalization [USA15] MUST NOT be applied at any point to either the JSON string or the string it is to be compared against.
2. Unicode正規化[USA15]は、JSON文字列またはそれが比較される文字列のいずれかに任意の時点で適用してはなりません。
3. Comparisons between the two strings MUST be performed as a Unicode code-point-to-code-point equality comparison.
3. 2つの文字列間の比較は、Unicodeコードポイントとコードポイントの等式比較として実行する必要があります。
Note that this is the same equality comparison procedure as that described in Section 8.3 of [RFC8259].
これは、[RFC8259]のセクション8.3で説明されているものと同じ平等比較手順であることに注意してください。
Implementations MUST support TLS. They MUST follow the guidance in [BCP195], which provides recommendations and requirements for improving the security of deployed services that use TLS.
実装はTLSをサポートする必要があります。彼らは[BCP195]のガイダンスに従う必要があります。これは、TLSを使用する展開されたサービスのセキュリティを改善するための推奨事項と要件を提供します。
The use of TLS at the protected resource metadata URLs protects against information disclosure and tampering.
保護されたリソースメタデータURLでのTLSの使用は、情報の開示と改ざんから保護します。
The scopes_supported parameter is the list of scopes the resource server is willing to disclose that it supports. It is not meant to indicate that an OAuth client should request all scopes in the list. The client SHOULD still follow OAuth best practices and request tokens with as limited a scope as possible for the given operation, as described in Section 2.3 of "Best Current Practice for OAuth 2.0 Security" [RFC9700].
SCOPES_SUPPORTEDパラメーターは、リソースサーバーがサポートすることを喜んで開示するSCOPESのリストです。OAUTHクライアントがリスト内のすべてのスコープを要求する必要があることを示すことは意図されていません。クライアントは引き続きOAUTHのベストプラクティスに従い、「OAUTH 2.0セキュリティの最良の現在のプラクティス」[RFC9700]のセクション2.3で説明されているように、特定の操作のスコープをできるだけ制限されたトークンを要求する必要があります。
TLS certificate checking MUST be performed by the client as described in [RFC9525] when making a protected resource metadata request. Checking that the server certificate is valid for the resource identifier URL prevents adversary-in-the-middle and DNS-based attacks. These attacks could cause a client to be tricked into using an attacker's resource server, which would enable impersonation of the legitimate protected resource. If an attacker can accomplish this, they can access the resources that the affected client has access to, using the protected resource that they are impersonating.
保護されたリソースメタデータリクエストを作成する場合は、[RFC9525]で説明されているように、クライアントがTLS証明書のチェックを実行する必要があります。サーバー証明書がリソース識別子URLに対して有効であることを確認すると、中間およびDNSベースの攻撃を防ぎます。これらの攻撃により、クライアントが攻撃者のリソースサーバーを使用してだまされる可能性があり、これにより、正当な保護されたリソースのなりすましが可能になります。攻撃者がこれを達成できる場合、影響を受けるクライアントがアクセスできるリソースにアクセスできます。
An attacker may also attempt to impersonate a protected resource by publishing a metadata document that contains a resource metadata parameter using the resource identifier URL of the protected resource being impersonated but that contains information of the attacker's choosing. This would enable it to impersonate that protected resource, if accepted by the client. To prevent this, the client MUST ensure that the resource identifier URL it is using as the prefix for the metadata request exactly matches the value of the resource metadata parameter in the protected resource metadata document received by the client, as described in Section 3.3.
また、攻撃者は、偽装されている保護されたリソースのリソース識別子URLを使用してリソースメタデータパラメーターを含むメタデータドキュメントを公開することにより、保護されたリソースになりすまそうとする場合がありますが、攻撃者の選択の情報が含まれています。これにより、クライアントが受け入れた場合、その保護されたリソースになりすまします。これを防ぐために、クライアントは、メタデータ要求のプレフィックスとして使用しているリソース識別子URLが、セクション3.3で説明されているように、クライアントが受け取った保護されたリソースメタデータドキュメントのリソースメタデータパラメーターの値と正確に一致することを確認する必要があります。
If a client expects to interact with multiple resource servers, the client SHOULD request audience-restricted access tokens using [RFC8707], and the authorization server SHOULD support audience-restricted access tokens.
クライアントが複数のリソースサーバーと対話することを期待している場合、クライアントは[RFC8707]を使用してオーディエンス制限のアクセストークンを要求する必要があり、認証サーバーはオーディエンス制限のアクセストークンをサポートする必要があります。
Without audience-restricted access tokens, a malicious resource server (RS1) may be able to use the WWW-Authenticate header to get a client to request an access token with a scope used by a legitimate resource server (RS2), and after the client sends a request to RS1, then RS1 could reuse the access token at RS2.
オーディエンス制限のアクセストークンがなければ、悪意のあるリソースサーバー（RS1）は、www-authenticateヘッダーを使用して、クライアントに正当なリソースサーバー（RS2）が使用するスコープでアクセストークンを要求することができ、クライアントがRS1にリクエストを送信した後、RS1はRS2でアクセストークンを復活させる可能性があります。
While this attack is not explicitly enabled by this specification and is possible in a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of dynamically configured clients. As such, the use of audience-restricted access tokens and Resource Indicators [RFC8707] is RECOMMENDED when using the features in this specification.
この攻撃は、この仕様によって明示的に有効にされておらず、プレーンOAuth 2.0の展開で可能ですが、動的に構成されたクライアントの使用により多少可能になります。そのため、この仕様の機能を使用する場合は、オーディエンス制限のアクセストークンとリソースインジケーター[RFC8707]の使用をお勧めします。
Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to use the protected resource. Whether a protected resource publishes its metadata in an ad hoc manner or in the standard format defined by this specification, the same defenses against attacks that might be mounted that use this information should be applied.
保護されたリソースに関する情報を標準形式で公開すると、正当なクライアントと攻撃者の両方が保護されたリソースを使用することが容易になります。保護されたリソースがメタデータをアドホックな方法で公開するか、この仕様で定義された標準形式で公開している場合でも、この情報を使用する可能性のある攻撃に対する同じ防御を適用する必要があります。
To support use cases in which the set of legitimate authorization servers to use with the protected resource is enumerable, this specification defines the authorization_servers metadata parameter, which enables explicitly listing them. Note that if the set of legitimate protected resources to use with an authorization server is also enumerable, lists in the protected resource metadata and authorization server metadata should be cross-checked against one another for consistency when these lists are used by the application profile.
保護されたリソースで使用する合法的な認証サーバーのセットが列挙可能であるユースケースをサポートするために、この仕様はauthorization_serversメタデータパラメーターを定義し、それらを明示的にリストすることを可能にします。認証サーバーで使用する合法的な保護されたリソースのセットも列挙可能である場合、保護されたリソースメタデータと認証サーバーメタデータのリストは、これらのリストをアプリケーションプロファイルで使用する場合、一貫性を互いにクロスチェックする必要があることに注意してください。
Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope for this specification. This specification assumes that the client has a means of determining appropriate authorization servers to use with a protected resource and that the client is using the correct metadata for each protected resource. Implementers need to be aware that if an inappropriate authorization server is used by the client, an attacker may be able to act as an adversary-in-the-middle proxy to a valid authorization server without it being detected by the authorization server or the client.
すべてのユースケースに対して保護されたリソースで使用する適切な承認サーバーの安全な決定は、この仕様の範囲外です。この仕様は、クライアントが保護されたリソースで使用する適切な認証サーバーを決定する手段を持っていること、およびクライアントが保護された各リソースに正しいメタデータを使用していることを前提としています。実装者は、クライアントが不適切な承認サーバーを使用している場合、攻撃者は、認証サーバーまたはクライアントによって検出されることなく、有効な承認サーバーの敵対的なプロキシとして機能することができることに注意する必要があります。
The ways to determine the appropriate authorization servers to use with a protected resource are, in general, application dependent. For instance, some protected resources are used with a fixed authorization server or a set of authorization servers, the locations of which may be known via out-of-band mechanisms. Alternatively, as described in this specification, the locations of the authorization servers could be published by the protected resource as metadata values. In other cases, the set of authorization servers that can be used with a protected resource can be dynamically changed by administrative actions or by changes to the set of authorization servers adhering to a trust framework. Many other means of determining appropriate associations between protected resources and authorization servers are also possible.
保護されたリソースで使用する適切な承認サーバーを決定する方法は、一般に、アプリケーションに依存します。たとえば、一部の保護されたリソースは、固定承認サーバーまたは一連の承認サーバーで使用されます。あるいは、この仕様で説明されているように、認証サーバーの場所は、保護されたリソースによってメタデータ値として公開される可能性があります。それ以外の場合、保護されたリソースで使用できる一連の承認サーバーは、管理アクションまたは信頼フレームワークに忠実な一連の承認サーバーの変更によって動的に変更できます。保護されたリソースと承認サーバー間の適切な関連性を決定する他の多くの手段も可能です。
The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server metadata. Since this specification enables clients to interoperate with RSs and ASes it has no prior knowledge of, this opens a risk for Server-Side Request Forgery (SSRF) attacks by malicious users or malicious resource servers. Clients SHOULD take appropriate precautions against SSRF attacks, such as blocking requests to internal IP address ranges. Further recommendations can be found in the Open Worldwide Application Security Project (OWASP) SSRF Prevention Cheat Sheet [OWASP.SSRF].
OAUTHクライアントは、リソースサーバーメタデータの発行者の値に基づいて、認証サーバーメタデータを取得することが期待されています。この仕様により、クライアントはRSSとASEと相互運用できるため、事前知識がないため、これにより、悪意のあるユーザーまたは悪意のあるリソースサーバーによるサーバー側のリクエスト偽造（SSRF）攻撃のリスクが開かれます。クライアントは、内部IPアドレス範囲への要求をブロックするなど、SSRF攻撃に対して適切な予防策を講じる必要があります。さらなる推奨事項は、Open Worldwide Application Security Project（OWASP）SSRF Preventionチートシート[owasp.ssrf]に記載されています。
This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL. If this resource is malicious or compromised, it could mislead the user into revealing their account credentials or authorizing unwanted access to OAuth-controlled capabilities. This risk is reduced, but not eliminated, by following best practices for OAuth user interfaces, such as providing clear notice to the user, displaying the authorization server's domain name, supporting origin-bound phishing-resistant authenticators, supporting the use of password managers, and applying heuristic checks such as domain reputation.
この仕様は、ユーザー選択のURLによって目的のHTTPリソースが識別されるシナリオに展開される場合があります。このリソースが悪意のあるまたは侵害されている場合、ユーザーがアカウントの資格情報を明らかにしたり、OAUTH制御機能への不要なアクセスを許可したりするように誤解を招く可能性があります。このリスクは、ユーザーへの明確な通知を提供したり、認証サーバーのドメイン名を表示したり、出身のフィッシング耐性認証器をサポートしたり、パスワードマネージャーの使用をサポートしたり、ドメインの評判などのヒューリスティックチェックを適用したりするなど、OAUTHユーザーインターフェイスのベストプラクティスに従うことで削減されません。
Unsigned metadata is integrity protected by the use of TLS at the site where it is hosted. This means that its security is dependent upon the Internet Public Key Infrastructure using X.509 (PKIX), as described in [RFC9525]. Signed metadata is additionally integrity protected by the JWS signature applied by the issuer, which is not dependent upon the Internet PKI.
署名されていないメタデータは、ホストされているサイトでTLSを使用することによって保護されています。これは、[RFC9525]に記載されているように、そのセキュリティはX.509（PKIX）を使用してインターネット公開キーインフラストラクチャに依存していることを意味します。署名されたメタデータは、インターネットPKIに依存しない発行者によって適用されるJWS署名によってさらに保護されています。
When using unsigned metadata, the party issuing the metadata is the protected resource itself, which is represented by the resource value in the metadata, whereas when using signed metadata, the party issuing the metadata is represented by the iss (issuer) claim in the signed metadata. When using signed metadata, applications can make trust decisions based on the issuer that performed the signing -- information that is not available when using unsigned metadata. How these trust decisions are made is out of scope for this specification.
署名されていないメタデータを使用する場合、メタデータを発行する当事者は保護されたリソース自体であり、これはメタデータのリソース値で表されますが、署名されたメタデータを使用する場合、メタデータを発行する当事者は署名されたメタデータのISS（ISSUER）請求によって表されます。署名済みのメタデータを使用する場合、アプリケーションは、署名を実行した発行者に基づいて信頼の決定を下すことができます。これらの信頼の決定がどのように行われるかは、この仕様の範囲外です。
Protected resource metadata is retrieved using an HTTP GET request, as specified in Section 3.1. Normal HTTP caching behaviors apply, meaning that the GET request may retrieve a cached copy of the content, rather than the latest copy. Implementations should utilize HTTP caching directives such as Cache-Control with max-age, as defined in [RFC9111], to enable caching of retrieved metadata for appropriate time periods.
保護されたリソースメタデータは、セクション3.1で指定されているように、HTTP GETリクエストを使用して取得されます。通常のHTTPキャッシュ動作が適用されます。つまり、GETリクエストは、最新のコピーではなく、コンテンツのキャッシュされたコピーを取得する可能性があります。実装は、[RFC9111]で定義されているように、最大年齢とのキャッシュコントロールなどのHTTPキャッシングディレクティブを利用して、適切な期間に取得したメタデータのキャッシュを可能にする必要があります。
Values are registered via Specification Required [RFC8126]. Registration requests should be sent to <oauth-ext-review@ietf.org> to initiate a two-week review period. However, to allow for the allocation of values prior to publication of the final version of a specification, the designated experts may approve registration once they are satisfied that the specification will be completed and published. However, if the specification is not completed and published in a timely manner, as determined by the designated experts, the designated experts may request that IANA withdraw the registration.
値は、必要な仕様を介して登録されます[RFC8126]。登録リクエストは、2週間のレビュー期間を開始するには、<oauth-ext-review@ietf.org>に送信する必要があります。ただし、仕様の最終バージョンの公開前に値の割り当てを可能にするために、指定された専門家は、仕様が完了して公開されることに満足した後、登録を承認することができます。ただし、指定された専門家によって決定されたように、仕様が完了して公開されていない場合、指定された専門家は、IANAが登録を撤回するよう要求する場合があります。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Protected Resource Metadata: example").
レビューのためにメーリングリストに送信された登録リクエストは、適切な科目を使用する必要があります（例：「OAUTH保護されたリソースメタデータを登録するリクエスト：例」）。
Within the review period, the designated experts 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. If the designated experts are not responsive, the registration requesters should contact IANA to escalate the process.
レビュー期間内に、指定された専門家は登録要求を承認または拒否し、この決定をレビューリストとIANAに伝えます。拒否には説明を含める必要があります。必要に応じて、リクエストを成功させる方法に関する提案が含まれます。指定された専門家が応答しない場合、登録要求者はIANAに連絡してプロセスをエスカレートする必要があります。
Designated experts should apply the following criteria when reviewing proposed registrations: They must be unique -- that is, they should not duplicate existing functionality; they are likely generally applicable, as opposed to being used for a single application; and they are clear and fit the purpose of the registry.
指定された専門家は、提案された登録をレビューする際に次の基準を適用する必要があります。それらは一意でなければなりません。つまり、既存の機能を複製すべきではありません。単一のアプリケーションに使用されるのではなく、一般的に適用可能である可能性があります。そして、それらは明確で、レジストリの目的に適合しています。
IANA must only accept registry updates from the designated experts and should direct all requests for registration to the review mailing list.
IANAは、指定された専門家からのレジストリの更新のみを受け入れる必要があり、登録のすべての要求をレビューメーリングリストに指示する必要があります。
In order to enable broadly informed review of registration decisions, there should be multiple designated experts to represent the perspectives of different applications using this specification. In cases where registration may be perceived as a conflict of interest for a particular expert, that expert should defer to the judgment of the other experts.
登録決定の広く情報に基づいたレビューを有効にするために、この仕様を使用して異なるアプリケーションの視点を表すために、複数の指定された専門家がいる必要があります。登録が特定の専門家にとって利益相反として認識される場合がある場合、その専門家は他の専門家の判断に延期すべきです。
The mailing list is used to enable public review of registration requests, which enables both designated experts and other interested parties to provide feedback on proposed registrations. Designated experts may allocate values prior to publication of the final specification. This allows authors to receive guidance from the designated experts early, so any identified issues can be fixed before the final specification is published.
メーリングリストは、登録要求の公開レビューを有効にするために使用されます。これにより、指定された専門家と他の利害関係者の両方が、提案された登録に関するフィードバックを提供できます。指定された専門家は、最終仕様の公開前に値を割り当てることができます。これにより、著者は指定された専門家から早期にガイダンスを受け取ることができるため、特定された問題は最終仕様が公開される前に修正できます。
This specification establishes the "OAuth Protected Resource Metadata" registry for OAuth 2.0 protected resource metadata names. The registry records the protected resource metadata parameter and a reference to the specification that defines it.
この仕様は、OAUTH 2.0保護されたリソースメタデータ名の「OAuth保護されたリソースメタデータ」レジストリを確立します。レジストリは、保護されたリソースメタデータパラメーターと、それを定義する仕様への参照を記録します。
Metadata Name:
メタデータ名：
The name requested (e.g., "resource"). This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the designated experts state that there is a compelling reason to allow an exception.
要求された名前（例：「リソース」）。この名前はケースに敏感です。指定された専門家が例外を許可する説得力のある理由があると述べていない限り、名前は他の登録名と一致しない場合があります。
Metadata Description:
メタデータの説明：
Brief description of the metadata (e.g., "Resource identifier URL").
メタデータの簡単な説明（例：「リソース識別子URL」）。
Change Controller:
Change Controller：
For IETF Stream RFCs, list "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
IETFストリームRFCSの場合、「IETF」をリストします。他の人のために、責任者の名前を与えてください。その他の詳細（例：郵便アドレス、メールアドレス、ホームページURI）も含めることができます。
Specification Document(s):
仕様文書：
Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
パラメーターを指定するドキュメントまたはドキュメントへの参照、できればドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
Metadata Name:
メタデータ名：
resource
リソース
Metadata Description:
メタデータの説明：
Protected resource's resource identifier URL
保護されたリソースのリソース識別子URL
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
authorization_servers
authorization_servers
Metadata Description:
メタデータの説明：
JSON array containing a list of OAuth authorization server issuer identifiers
OAuth Authorization Server発行具のリストを含むJSONアレイ
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
jwks_uri
jwks_uri
Metadata Description:
メタデータの説明：
URL of the protected resource's JWK Set document
保護されたリソースのJWKセットドキュメントのURL
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
scopes_supported
scopes_supported
Metadata Description:
メタデータの説明：
JSON array containing a list of the OAuth 2.0 scope values that are used in authorization requests to request access to this protected resource
JSONアレイこの保護されたリソースへのアクセスをリクエストするための承認リクエストで使用されるOAUTH 2.0スコープ値のリストを含む
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
bearer_methods_supported
Bearer_methods_supported
Metadata Description:
メタデータの説明：
JSON array containing a list of the OAuth 2.0 bearer token presentation methods that this protected resource supports
この保護されたリソースがサポートするOAUTH 2.0 BEARER TOKENプレゼンテーション方法のリストを含むJSONアレイ
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
resource_signing_alg_values_supported
resource_singe_alg_values_supported
Metadata Description:
メタデータの説明：
JSON array containing a list of the JWS signing algorithms (alg values) supported by the protected resource for signed content
JSONアレイ署名されたコンテンツの保護されたリソースによってサポートされるJWS署名アルゴリズム（アルグ値）のリストを含む
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
resource_name
resource_name
Metadata Description:
メタデータの説明：
Human-readable name of the protected resource
保護されたリソースの人間の読み取り可能な名前
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
resource_documentation
resource_documentation
Metadata Description:
メタデータの説明：
URL of a page containing human-readable information that developers might want or need to know when using the protected resource
開発者が保護されたリソースを使用するときに必要な人間の読み取り可能な情報を含むページのURL
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
resource_policy_uri
resource_policy_uri
Metadata Description:
メタデータの説明：
URL of a page containing human-readable information about the protected resource's requirements on how the client can use the data provided by the protected resource
保護されたリソースが提供するデータを保護されたリソースを使用する方法に関する保護されたリソースの要件に関するヒューマン読み取り可能な情報を含むページのURL
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
resource_tos_uri
resource_tos_uri
Metadata Description:
メタデータの説明：
URL of a page containing human-readable information about the protected resource's terms of service
保護されたリソースのサービス利用規約に関する人間が読み取る可能な情報を含むページのURL
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
tls_client_certificate_bound_access_tokens
tls_client_certificate_bound_access_tokens
Metadata Description:
メタデータの説明：
Boolean value indicating protected resource support for mutual-TLS client certificate-bound access tokens
相互TLSクライアントの証明書バウンドアクセストークンの保護されたリソースサポートを示すブール値
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
authorization_details_types_supported
authorization_details_types_supported
Metadata Description:
メタデータの説明：
JSON array containing a list of the authorization details type values supported by the resource server when the authorization_details request parameter is used
Authorization_Details要求パラメーターが使用されているときにリソースサーバーでサポートされる承認詳細のリストのリストを含むJSONアレイ
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
dpop_signing_alg_values_supported
dpop_singe_alg_values_supported
Metadata Description:
メタデータの説明：
JSON array containing a list of the JWS alg values supported by the resource server for validating DPoP proof JWTs
JSONアレイDPOPプルーフJWTSを検証するためにリソースサーバーがサポートするJWSアルグ値のリストを含む
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
dpop_bound_access_tokens_required
dpop_bound_access_tokens_required
Metadata Description:
メタデータの説明：
Boolean value specifying whether the protected resource always requires the use of DPoP-bound access tokens
保護されたリソースが常にDPOPバウンドアクセストークンの使用を必要とするかどうかを指定するブール値
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2 of RFC 9728
RFC 9728のセクション2
Metadata Name:
メタデータ名：
signed_metadata
signed_metadata
Metadata Description:
メタデータの説明：
Signed JWT containing metadata parameters about the protected resource as claims
保護されたリソースに関するメタデータパラメーターを含むJWTに署名された主張として
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 2.2 of RFC 9728
RFC 9728のセクション2.2
IANA has registered the following authorization server metadata parameter in the "OAuth Authorization Server Metadata" registry established in "OAuth 2.0 Authorization Server Metadata" [RFC8414].
IANAは、「OAuth 2.0 Authorization Server Metadata」[RFC8414]に確立された「OAuth Authorization Server Metadata」レジストリに次の承認サーバーメタデータパラメーターを登録しました。
Metadata Name:
メタデータ名：
protected_resources
protected_resources
Metadata Description:
メタデータの説明：
JSON array containing a list of resource identifiers for OAuth protected resources
OAuth保護されたリソースのリソース識別子のリストを含むJSONアレイ
Change Controller:
Change Controller：
IETF
IETF
Specification Document(s):
仕様文書：
Section 4 of RFC 9728
RFC 9728のセクション4
This specification registers the well-known URI defined in Section 3 in the "Well-Known URIs" registry [IANA.well-known].
この仕様は、「よく知られているURIS」レジストリ[IANA.Well-Conking]のセクション3で定義されているよく知られているURIを登録します。
URI Suffix:
URIサフィックス：
oauth-protected-resource
oauth保護されたリソース
Reference:
参照：
Section 3 of RFC 9728
RFC 9728のセクション3
Status:
状態：
permanent
永続
Change Controller:
Change Controller：
IETF
IETF
Related Information:
関連情報：
(none)
（なし）
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
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>.
[BCP47] Best Current Practice 47,
<https://www.rfc-editor.org/info/bcp47>.
At the time of writing, this BCP comprises the following:
Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September
2006, <https://www.rfc-editor.org/info/rfc4647>.
Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[IANA.Language]
IANA, "Language Subtag Registry",
<https://www.iana.org/assignments/language-subtag-
registry>.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[JWS] 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>.
[JWT] 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>.
[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>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[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>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<https://www.unicode.org/versions/latest/>.
[USA15] Whistler, K., Ed., "Unicode Normalization Forms", Unicode
Standard Annex #15, 14 August 2024,
<https://www.unicode.org/reports/tr15/>.
[FAPI.MessageSigning]
Tonge, D. and D. Fett, "FAPI 2.0 Message Signing (Draft)",
24 March 2023,
<https://openid.net/specs/fapi-2_0-message-signing.html>.
[IANA.JOSE]
IANA, "JSON Web Signature and Encryption Algorithms",
<https://www.iana.org/assignments/jose>.
[IANA.well-known]
IANA, "Well-Known URIs",
<https://www.iana.org/assignments/well-known-uris>.
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0 incorporating errata set 2", 15
December 2023, <https://openid.net/specs/openid-connect-
discovery-1_0.html>.
[OWASP.SSRF]
OWASP Foundation, "OWASP Server-Side Request Forgery
Prevention Cheat Sheet",
<https://cheatsheetseries.owasp.org/cheatsheets/
Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application
Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
2019, <https://www.rfc-editor.org/info/rfc8620>.
[RFC9470] Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up
Authentication Challenge Protocol", RFC 9470,
DOI 10.17487/RFC9470, September 2023,
<https://www.rfc-editor.org/info/rfc9470>.
[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>.
The authors of this specification would like to thank the attendees of the IETF 115 OAuth and HTTP API Working Group meetings and the attendees of subsequent OAuth Working Group meetings for their input on this specification. We would also like to thank Amanda Baber, Mike Bishop, Ralph Bragg, Brian Campbell, Deb Cooley, Gabriel Corona, Roman Danyliw, Vladimir Dzhuvinov, George Fletcher, Arnt Gulbrandsen, Pieter Kasselman, Murray Kucherawy, David Mandelberg, Tony Nadalin, Francesca Palombini, John Scudder, Rifaat Shekh-Yusef, Filip Skokan, Orie Steele, Atul Tulshibagwale, Éric Vyncke, Paul Wouters, and Bo Wu for their contributions to the specification.
この仕様の著者は、IETF 115 OAuthおよびHTTP APIワーキンググループミーティングの参加者と、この仕様に関する入力についてその後のOAuthワーキンググループミーティングの参加者に感謝します。また、アマンダ・ババー、マイク・ビショップ、ラルフ・ブラッグ、ブライアン・キャンベル、デブ・クーリー、ガブリエル・コロナ、ローマン・ダニリウ、ジョージ・フレッチャー、ジョージ・フレッチャー、アルント・ガルブランセン、ピーター・ケーセルマン、ムーレ・クエラウィ、ダビデ・マンデルマン、タニー・ナダルンマンにも感謝します。Scudder、Rifaat Shekh-Yusef、Filip Skokan、Orie Steele、Atul Tulshibagwale、éricVyncke、Paul Wouters、およびBo Wuの仕様への貢献について。
Michael B. Jones
Self-Issued Consulting
Email: michael_b_jones@hotmail.com
URI: https://self-issued.info/
Phil Hunt
Independent Identity, Inc.
Email: phil.hunt@yahoo.com
Aaron Parecki
Okta
Email: aaron@parecki.com
URI: https://aaronparecki.com/