Skip to content

OAuth 2.0 Protected Resource Metadata

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

Abstract

本仕様は、OAuth 2.0クライアントまたはAuthorization Serverが、OAuth 2.0で保護されたリソースと連携するために必要な情報を取得する際に利用できるメタデータ形式を定義する。

Status of This Memo

本文章は、インターネット標準トラックの文書である。

本文章はInternet Engineering Task Force (IETF) の成果物である。IETFコミュニティの合意を表す。公的なレビューを受け、Internet Engineering Steering Group (IESG) により公開承認を得ている。インターネット標準に関する追加情報はRFC 7841のSection 2にある。

本文書の現行ステータス、正誤表、およびフィードバックの提供方法については、以下で入手できる。\ https://www.rfc-editor.org/info/rfc9728.

Copyright (c) 2025 IETF Trust および本文書の著者として特定された者。無断転載を禁ずる。

本文書は、本文書の公開日時点で有効なBCP 78およびIETF Trustの「IETF Documentsに関する法的規定」\ (https://trustee.ietf.org/license-info) の対象となる。これらの文書には、本文章に関する権利および制限が記載されているため、注意深く確認すること。本文書から抽出されたコード部品には、Trust Legal ProvisionsのSection 4.eに記載されたRevised BSD Licenseの文言を含めなければならず、またRevised BSD Licenseに記載のとおり保証なしで提供される。

Table of Contents

1. Introduction

本仕様は、OAuth 2.0クライアントおよびAuthorization Serverが、OAuth 2.0で保護されたリソースと連携するために必要な情報を取得できるようにするメタデータ形式を定義する。本仕様の構造と内容は、意図的に、(1) クライアントが自身に関するメタデータをOAuth 2.0 Authorization Serverへ提供できるようにする「OAuth 2.0 Dynamic Client Registration Protocol」[RFC7591]、および(2) クライアントがOAuth 2.0 Authorization Serverに関するメタデータを取得できるようにする「OAuth 2.0 Authorization Server Metadata」[RFC8414] と、可能な限り並行になるようにしてある。

クライアントが保護対象リソースの場所をどのように取得するかは、本文章のスコープ外である。場合によっては、その場所がクライアントに手動設定されることがある。例えば、メールクライアントが、ユーザが自身のJSON Meta Application Protocol (JMAP) サーバ [RFC8620] のURLを入力するためのインターフェースを提供する、といった具合である。別の場合には、動的に発見されることもある。例えば、ユーザがメールアドレスをメールクライアントに入力し、クライアントがWebFingerディスカバリ [RFC7033]（[OpenID.Discovery] のSection 2の記述に関連する方法）を実行してResource Serverを見つけ、続いてクライアントがResource Serverメタデータを取得して、ユーザのメールへアクセスする認可を得るために使用するAuthorization Serverを見つけることができる。

保護対象リソースのメタデータは、well-knownな場所から、JSON [RFC8259] 文書として取得される。この文書は、その機能（capabilities）および、任意で、他サービスとの関係性を宣言する。このプロセスはSection 3で説明する。

このメタデータは、自己主張（self-asserted）の形でも、あるいはJSON Web Token (JWT) [JWT] 内のclaimsとして表現された署名付きメタデータ値の集合としても、伝達できる。JWTの場合、issuerは保護対象リソースに関するデータの妥当性を保証している。これは、OAuth Dynamic Client Registration [RFC7591] におけるsoftware statementの役割に類似する。

自身に関するメタデータを公開する各保護対象リソースは、Resource Serverが複数の保護対象リソースを実装している場合であっても、保護対象リソースのURLから決定的に導出されるwell-knownな場所に、自身のメタデータ文書を提供する。これにより、Section 7.3で説明するように、攻撃者が「保護対象リソースを説明しているはずだが実際には保護対象リソースに対して権威的ではない」メタデータを公開することを防ぐ。

Section 2は、保護対象リソースが公開できるメタデータ・パラメータを定義する。これには、どのscopeがサポートされているか、クライアントがどのようにAccess Tokenを提示できるか、などが含まれる。これらの値（例えばjwks_uri（Section 2参照））は他の仕様と併用できる。例えば、jwks_uriで公開された公開鍵は、[FAPI.MessageSigning] で説明されているように、署名付きリソース応答を検証するために利用できる。

Section 5は、保護対象リソースがWWW-Authenticateを用いて、保護対象リソース・メタデータのURLをクライアントへ動的に通知する方法を説明する。このWWW-Authenticateの利用により、保護対象リソース・メタデータが変更された可能性があることを示せる。

1.1. Requirements Notation and Conventions

本文書中のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すように全て大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] で記述されるとおりに解釈される。

本仕様で議論するJSON Web Signature (JWS) データ構造 [JWS] およびJSON Web Encryption (JWE) データ構造 [JWE] の適用はすべて、JWS Compact SerializationまたはJWE Compact Serializationを用いる。JWS JSON SerializationおよびJWE JSON Serializationは使用しない。単一のシリアライゼーションを選ぶことは、相互運用性の促進を意図している。

1.2. Terminology

本仕様は、OAuth 2.0 [RFC6749] で定義される「access token」「authorization code」「authorization server」「client」「client authentication」「client identifier」「protected resource」「resource server」という用語、および「JSON Web Token (JWT)」[JWT] で定義される「Claim Name」と「JSON Web Token (JWT)」という用語を使用する。

本仕様は次の用語を定義する:

Resource Identifier:\ 保護対象リソースのリソース識別子。これはhttpsスキームを使用し、フラグメント要素を含まないURLである。[RFC8707] のSection 2で規定されているとおり、クエリ要素も含めないことが望ましい（SHOULD NOT）。ただし、クエリ要素がリソース識別子の有用かつ必要な一部となる場合があることも認識されている。保護対象リソース・メタデータは、Section 3で説明するように、このリソース識別子から導出される.well-knownな場所 [RFC8615] で公開される。

2. Protected Resource Metadata

保護対象リソースは、その設定を説明するメタデータを持つことができる。本仕様で使用され、Section 8.1で確立される「OAuth Protected Resource Metadata」レジストリに登録される、以下の保護対象リソース・メタデータ・パラメータを本仕様は用いる:

  • resource\ REQUIRED。Section 1.2で定義される、保護対象リソースのリソース識別子。
  • authorization_servers\ OPTIONAL。JSON配列であり、この保護対象リソースで使用できるOAuth authorization serverのissuer識別子の一覧を含む。issuer識別子は [RFC8414] で定義される。保護対象リソースは、このパラメータを使用する場合であっても、サポートするauthorization serverの一部を広告しない（公開しない）ことを選んでもよい（MAY）。ユースケースによっては、authorization serverの集合を列挙できない場合があり、その場合このメタデータ・パラメータは使用しない。
  • jwks_uri\ OPTIONAL。保護対象リソースのJSON Web Key (JWK) Set [JWK] 文書のURL。これには、Resource Serverがリソース応答に署名するために使用する署名鍵など、保護対象リソースに属する公開鍵が含まれる。このURLはhttpsスキームを使用しなければならない（MUST）。署名鍵と暗号化鍵の両方を公開する場合、参照されるJWK Set内の全ての鍵について、各鍵の意図された用途を示すuse (public key use) パラメータ値が必須である（REQUIRED）。
  • scopes_supported\ RECOMMENDED。JSON配列であり、この保護対象リソースへのアクセスを要求するために認可リクエストで使用されるscope値の一覧を含む。scope値はOAuth 2.0 [RFC6749] で定義される。保護対象リソースは、このパラメータを使用する場合であっても、サポートするscope値の一部を広告しないことを選んでもよい（MAY）。
  • bearer_methods_supported\ OPTIONAL。JSON配列であり、OAuth 2.0 bearer token [RFC6750] を保護対象リソースへ送信する際にサポートされる方法の一覧を含む。定義済みの値は ["header", "body", "query"] であり、[RFC6750] のSection 2.1、2.2、2.3に対応する。空配列 [] は、bearer methodがサポートされないことを示すために使用できる。本エントリが省略された場合、デフォルトのbearer methodがサポートされることは含意されず、また省略されていること自体が「サポートされない」ことを示すわけでもない。
  • resource_signing_alg_values_supported\ OPTIONAL。JSON配列であり、保護対象リソースがリソース応答に署名するためにサポートするJWS [JWS] 署名アルゴリズム（alg値）[JWA] の一覧を含む。例えば [FAPI.MessageSigning] に記述されている。ここが省略された場合、デフォルト・アルゴリズムは含意されない。値 none は使用してはならない（MUST NOT）。
  • resource_name\ End-Userに表示することを意図した、保護対象リソースの人間可読な名称。保護対象リソース・メタデータにこのフィールドを含めることが推奨される（RECOMMENDED）。このフィールドの値は、Section 2.1で説明するように国際化できる（MAY）。
  • resource_documentation\ OPTIONAL。開発者が保護対象リソースを利用する際に知りたい、または知る必要がある、人間可読な情報を含むページのURL。このフィールドの値は、Section 2.1で説明するように国際化できる（MAY）。
  • resource_policy_uri\ OPTIONAL。クライアントが保護対象リソースから提供されるデータをどのように利用できるかに関する要件について、人間可読な情報を含むページのURL。このフィールドの値は、Section 2.1で説明するように国際化できる（MAY）。
  • resource_tos_uri\ OPTIONAL。保護対象リソースの利用規約に関する人間可読な情報を含むページのURL。このフィールドの値は、Section 2.1で説明するように国際化できる（MAY）。
  • tls_client_certificate_bound_access_tokens\ OPTIONAL。mutual-TLSクライアント証明書に束縛されたAccess Token [RFC8705] を、保護対象リソースがサポートすることを示すBoolean値。省略された場合、デフォルト値はfalseである。
  • authorization_details_types_supported\ OPTIONAL。JSON配列であり、authorization_detailsリクエスト・パラメータ [RFC9396] が使用される際に、Resource Serverがサポートするauthorization details type値の一覧を含む。
  • dpop_signing_alg_values_supported\ OPTIONAL。JSON配列であり、Demonstrating Proof of Possession (DPoP) proof JWTs [RFC9449] を検証するために、Resource ServerがサポートするJWS alg値（「JSON Web Signature and Encryption Algorithms」レジストリ [IANA.JOSE] より）の一覧を含む。
  • dpop_bound_access_tokens_required\ OPTIONAL。保護対象リソースが常にDPoPに束縛されたAccess Token [RFC9449] の使用を要求するかどうかを指定するBoolean値。省略された場合、デフォルト値はfalseである。

追加の保護対象リソース・メタデータ・パラメータも使用できる（MAY）。

2.1. Human-Readable Resource Metadata

人間可読なリソース・メタデータ値、および人間可読なコンテンツを参照するリソース・メタデータ値は、複数の言語および文字体系で表現できる（MAY）。例えば、resource_name、resource_documentation、resource_tos_uri、resource_policy_uriなどのフィールドの値は、異なる場所での利用を容易にするために、ロケールごとの複数のメタデータ値を持ち得る。

言語および文字体系を指定するために、言語タグ [BCP47] を、# 文字で区切ってリソース・メタデータ・パラメータ名に付加する。JSON [RFC8259] で議論されるmember nameは大文字小文字を区別するため、Claim Nameで使用される言語タグ値は、「Language Subtag Registry」[IANA.Language] に登録されているとおりの大文字小文字で綴ることが推奨される（RECOMMENDED）。特に、通常は言語名は小文字、地域名は大文字、言語は混在ケース（mixed-case）で綴られる。ただし、[BCP47] により言語タグ値は大文字小文字を区別しないため、実装は供給された言語タグ値を大文字小文字を区別しない形で解釈するべきである（SHOULD）。[BCP47] の推奨に従い、メタデータ・パラメータ名で使用する言語タグ値は、必要な範囲でのみ具体的であるべきである。例えば、多くの文脈では、fr-CAやfr-FRではなくfrで十分かもしれない。

例えば、あるリソースは、英語での名称を "resource_name#en": "My Resource"、イタリア語での名称を "resource_name#it": "La mia bella risorsa" として、そのメタデータ内に表現できる。これらの名称の一部または全部をEnd-Userに表示してよい（MAY）。どの名称を表示するかは、システム設定、ユーザの好み、その他の要因に基づいて選択される。

人間可読フィールドが言語タグなしで送信された場合、それを使用する当事者は、その文字列値の言語・文字集合・文字体系について一切の仮定をしてはならず（MUST NOT）、ユーザインターフェースで提示される箇所では文字列値をそのまま使用しなければならない（MUST）。相互運用性を促進するため、提供される各種の人間可読メタデータについて、言語固有パラメータに加えて、言語タグを付けないメタデータ・パラメータのインスタンスも含めることが推奨される（RECOMMENDED）。また、言語タグなしで送信される人間可読フィールドには、幅広い種類のシステムで表示するのに適した値を含めることが推奨される（RECOMMENDED）。

2.2. Signed Protected Resource Metadata

JSON要素に加えて、メタデータ値はsigned_metadata値としても提供できる（MAY）。これは、保護対象リソースに関するメタデータ値を束ねて主張するJSON Web Token (JWT) [JWT] である。署名付きメタデータでclaimsとして使用できるメタデータ・パラメータの集合はSection 2で定義される。署名付きメタデータは、JSON Web Signature (JWS) [JWS] を用いて電子署名またはMAC（Message Authentication Codeによる保護）されなければならず（MUST）、署名付きメタデータ中のclaimsを証明する当事者を示すiss（issuer）claimを含まなければならない（MUST）。メタデータの利用者は、この機能をサポートしない場合、署名付きメタデータを無視してよい（MAY）。メタデータの利用者が署名付きメタデータをサポートする場合、署名付きメタデータで伝達されるメタデータ値は、平文のJSON要素で伝達される対応する値に優先しなければならない（MUST）。

署名付きメタデータは、以下のOPTIONALなメタデータ・パラメータを用いて、保護対象リソース・メタデータJSONオブジェクトに含められる:

  • signed_metadata\ 保護対象リソースに関するメタデータ・パラメータをclaimsとして含むJWT。これは、署名付きJWT全体からなる文字列値である。signed_metadataパラメータはJWT内でclaimとして出現してはならない（SHOULD NOT）。これが起きるメタデータは拒否することが推奨される（RECOMMENDED）。

3. Obtaining Protected Resource Metadata

メタデータをサポートする保護対象リソースは、Section 2で規定されるメタデータを含むJSON文書を、あらかじめ指定されたURLで利用可能にしなければならない（MUST）。このURLは、保護対象リソースのリソース識別子に対し、host要素と（存在するなら）path要素および/またはquery要素の間に、well-known URI文字列を挿入して形成する。デフォルトでは、使用されるwell-known URI文字列は /.well-known/oauth-protected-resource である。.well-knownの構文および意味は [RFC8615] で定義される。使用されるwell-known URIのpath suffixは、「Well-Known URIs」レジストリ [IANA.well-known] に登録されなければならない（MUST）。この構成の例はSection 3.1にある。

以下で用いる「application」という用語（[RFC8414] で用いられるものと同じ）は、ユースケースにおいてタスクを達成するために使用される全ての構成要素を包含する。これにはOAuthクライアント、Authorization Server、保護対象リソース、ならびに非OAuth構成要素が含まれ得る。また、それら各構成要素で実行されるコードも含む。applicationは特定の問題を解決するために構築され、多数の構成要素やサービスを利用することがある。

OAuthで保護されたリソースをapplication固有の方法で利用する異なるapplicationは、保護対象リソース・メタデータを公開するために、異なるwell-known URI path suffixを定義し登録できる（MAY）。例えば、Example applicationがOAuth protected resourceをExample固有の方法で利用し、Example固有のメタデータ値を公開する必要があるなら、example-protected-resource URI path suffixを登録して使用し、保護対象リソースのリソース識別子のhostと（存在するなら）pathおよび/またはquery要素の間に /.well-known/example-protected-resource を挿入して形成されるURLでメタデータ文書を公開できる。代替として、多くのapplicationはデフォルトのwell-known URI文字列 /.well-known/oauth-protected-resource を使用するだろう。これは汎用のOAuth protected resourceにとって正しい選択であり、application固有のものを登録しない。

本仕様を用いるOAuth 2.0 applicationは、この目的で使用するwell-known URI suffixを指定しなければならない（MUST）。同一の保護対象リソースは、そのリソース識別子から導出される複数のwell-knownな場所でメタデータを公開することを選んでもよい（MAY）。例えば、/.well-known/example-protected-resource と /.well-known/oauth-protected-resource の両方でメタデータを公開する、といった具合である。

3.1. Protected Resource Metadata Request

保護対象リソース・メタデータ文書は、前節で指定したURLに対するHTTP GETリクエストで問い合わせなければならない（MUST）。

リソース識別子が https://resource.example.com であり、well-known URI path suffixが oauth-protected-resource である場合、リソース識別子にpath要素がないため、メタデータの利用者は以下のリクエストを行う:

GET /.well-known/oauth-protected-resource HTTP/1.1
Host: resource.example.com

リソース識別子の値にpath要素またはquery要素が含まれる場合、host要素に続く終端スラッシュ (/) は、host要素とpathおよび/またはquery要素の間に /.well-known/ とwell-known URI path suffixを挿入する前に取り除かなければならない（MUST）。例えば、リソース識別子が https://resource.example.com/resource1 であり、well-known URI path suffixが oauth-protected-resource である場合、リソース識別子にpath要素が含まれるため、メタデータの利用者は以下のリクエストを行う:

GET /.well-known/oauth-protected-resource/resource1 HTTP/1.1
Host: resource.example.com

path要素を利用すると、1つのhostで複数のリソースをサポートできる。これは一部のマルチテナントホスティング構成で必要となる。.well-knownのこの利用は、1つのhostで複数のリソースをサポートするためのものであり、[RFC8615] における利用とは異なり、hostに関する一般情報を提供するものではない。

3.2. Protected Resource Metadata Response

応答は、保護対象リソースの設定に関するメタデータ・パラメータの集合である。成功応答はHTTPステータスコード200 OKを使用しなければならず（MUST）、application/json content typeを用いたJSONオブジェクトを返さなければならない（MUST）。このJSONオブジェクトは、Section 2で定義されるメタデータ・パラメータの部分集合であるメタデータ・パラメータ群をmemberとして含む。追加のメタデータ・パラメータを定義して使用してよい（MAY）。理解できないメタデータ・パラメータは無視しなければならない（MUST）。

複数値を持つパラメータはJSON配列として表現する。\ 値がゼロのパラメータは、応答から省略しなければならない（MUST）。

エラー応答は、適用可能なHTTPステータスコード値を使用する。

以下は非規範的な応答例である:

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"
}

3.3. Protected Resource Metadata Validation

返却されるresource値は、メタデータを取得するために作成したURL（保護対象リソースのリソース識別子値にwell-known URI path suffixを挿入したもの）における、保護対象リソースのリソース識別子値と同一でなければならない（MUST）。これらの値が同一でない場合、応答に含まれるデータは使用してはならない（MUST NOT）。

保護対象リソース・メタデータが、保護対象リソースからWWW-Authenticateのresource_metadataパラメータで返されたURLから取得された場合、返却されるresource値は、クライアントがResource Serverにリクエストを行う際に使用したURLと同一でなければならない（MUST）。これらの値が同一でない場合、応答に含まれるデータは使用してはならない（MUST NOT）。

これらの検証動作は、Section 7.3で説明するなりすまし攻撃を阻止できる。

受信者は、署名付きメタデータがissuerに属する鍵で署名されており、かつ署名が有効であることを検証しなければならない（MUST）。署名が検証できない場合、またはissuerが信頼できない場合、受信者はこれをエラー条件として扱うべきである（SHOULD）。

4. Authorization Server Metadata

Authorization Serverとともに使用する正当な保護対象リソースの集合を列挙できるユースケースを支援するために、本仕様はAuthorization Serverメタデータ・パラメータprotected_resourcesを定義する。これにより、Authorization Serverは保護対象リソースを明示的に列挙できる。なお、保護対象リソースとともに使用する正当なauthorization serverの集合も列挙できる場合、application profileでこれらのリストを使用する際には、Authorization Serverメタデータと保護対象リソース・メタデータのリスト同士を整合性のために相互検査するべきである。

以下のAuthorization Serverメタデータ・パラメータは本仕様により定義され、「OAuth 2.0 Authorization Server Metadata」[RFC8414] により確立される「OAuth Authorization Server Metadata」レジストリに登録される。

  • protected_resources\ OPTIONAL。JSON配列であり、このAuthorization Serverで使用できるOAuth protected resourceのresource identifierの一覧を含む。Authorization Serverは、このパラメータを使用する場合であっても、サポートする保護対象リソースの一部を広告しないことを選んでもよい（MAY）。ユースケースによっては保護対象リソースの集合を列挙できない場合があり、その場合このメタデータ・パラメータは存在しない。

5. Use of WWW-Authenticate for Protected Resource Metadata

保護対象リソースは、[RFC9110] で議論されるWWW-Authenticate HTTP応答ヘッダフィールドを使用して、保護対象リソース・メタデータへのURLをクライアントに返してよい（MAY）。クライアントはその後、Section 3で説明するように保護対象リソース・メタデータを取得できる。クライアントは例えば、取得した保護対象リソース・メタデータに基づいて、そのリソースに対してどのAuthorization Serverを使用するかを判断できる。

このようにする典型的なエンドツーエンドのフローは次のとおりである。なお、この例はOAuth 2.0 Authorization Code Flowを使用しているが、同様の手順は他のOAuth Flowでも実装できる。

     +----------+              +----------+    +---------------+
     |  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

手順（Figure 1）

  1. クライアントは、Access Tokenを提示せずに保護対象リソースへリクエストを行う。
  2. Resource Serverは、保護対象リソース・メタデータのURLを含むWWW-Authenticateヘッダを付けて応答する。
  3. クライアントは、このURLから保護対象リソース・メタデータを取得する。
  4. Resource Serverは、Section 3.2に従って保護対象リソース・メタデータを返す。
  5. クライアントは、Section 3.3で説明するように保護対象リソース・メタデータを検証し、リソース・メタデータ中のissuer識別子から [RFC8414] に従ってAuthorization ServerメタデータURLを構築する。
  6. クライアントは、Authorization Serverメタデータを取得するためのリクエストを行う。
  7. Authorization Serverは、[RFC8414] に従ってAuthorization Serverメタデータ文書を返す。
  8. クライアントは、認可フローを開始するためにUser-AgentをAuthorization Serverへ誘導する。
  9. 認可のやり取りが完了し、Authorization ServerはAccess Tokenをクライアントへ返す。
  10. クライアントは、手順1のリソース要求を繰り返し、取得したAccess Tokenを提示する。
  11. Resource Serverは、要求された保護対象リソースを返す。

5.1. WWW-Authenticate Response

本仕様は、保護対象リソース・メタデータURLを示すために、WWW-Authenticate HTTP応答ヘッダフィールドに新しいパラメータを導入する:

  • resource_metadata\ 保護対象リソース・メタデータのURL。

以下の応答は、resource identifierを含むWWW-Authenticateヘッダの例である。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata=
  "https://resource.example.com/.well-known/oauth-protected-resource"

上記の例のHTTPステータスコードは [RFC6750] により定義される。

このパラメータは、「Bearer」[RFC6750] 以外の認可スキーム、例えば [RFC9449] で定義されるDPoPスキームを使用するWWW-Authenticate応答でも使用してよい（MAY）。

resource_metadataパラメータは、他の拡張で定義されるパラメータ、例えば [RFC9470] で定義されるmax_ageパラメータと組み合わせてよい（MAY）。

5.2. Changes to Resource Metadata

Resource Serverが定める任意の理由により、任意の時点で、保護対象リソースは、保護対象リソース・メタデータURLの値を含む新しいWWW-Authenticateチャレンジを返してよい（MAY）。これはメタデータが変更された可能性があることを示す。クライアントがそのようなWWW-Authenticate応答を受け取った場合、更新された保護対象リソース・メタデータを取得し、Section 3.3で説明するように検証したうえで、新たに得たメタデータ値を使用するべきである（SHOULD）。とりわけ、これによりResource Serverは、クライアントとのそれ以外の調整なしに、使用するAuthorization Serverを変更できる。

5.3. Client Identifier and Client Authentication

Authorization Serverにおいてclient identifierがどのように確立されるかは、本仕様のスコープ外である。

本仕様は、クライアントがResource Serverについて事前知識を持たない状況、およびResource Serverがクライアントについて事前知識を持つ場合と持たない場合の両方において、展開されることを意図している。

未認識のクライアントがAuthorization Serverを利用できる既存の方法がいくつかある。例えば、認可フローを開始する前にDynamic Client Registration [RFC7591] を用いてクライアントを登録する方法である。将来のOAuth拡張は、クライアントを識別するためにURLを使用するなど、代替案を定義する可能性がある。

5.4. Compatibility with Other Authentication Methods

Resource Serverは、さまざまな認証スキームを示す他のWWW-Authenticateヘッダを返してよい（MAY）。これによりResource Serverは、本仕様を実装するクライアントと実装しないクライアントの両方をサポートでき、クライアントは好みの認証スキームを選べる。

6. String Operations

一部のOAuth 2.0メッセージの処理では、メッセージ内の値を既知の値と比較する必要がある。例えば、メタデータ応答内のmember nameを、resourceなどの特定のmember nameと比較することがある。しかし、Unicode文字列 [UNICODE] の比較には、重大なセキュリティ上の意味合いがある。

したがって、JSON文字列と他のUnicode文字列の比較は、以下に指定するとおりに行わなければならない（MUST）:

  1. JSONで適用されたエスケープを解除し、Unicodeコードポイントの配列を生成する。
  2. Unicode正規化 [USA15] を、JSON文字列にも、比較対象の文字列にも、いかなる時点でも適用してはならない（MUST NOT）。
  3. 2つの文字列の比較は、Unicodeコードポイント同士の等価比較として実行しなければならない（MUST）。

これは、[RFC8259] のSection 8.3で記述される等価比較手順と同一であることに留意すること。

7. Security Considerations

7.1. TLS Requirements

実装はTLSをサポートしなければならない（MUST）。配備されたサービスでTLSを利用する際のセキュリティ改善に関する推奨および要件を提供する [BCP195] の指針に従わなければならない（MUST）。

保護対象リソース・メタデータURLでTLSを使用することは、情報漏えいおよび改ざんから保護する。

7.2. Scopes

scopes_supportedパラメータは、Resource Serverがサポートしていると開示する意思のあるscopeのリストである。これは、OAuthクライアントがそのリスト中の全てのscopeを要求すべきであることを意味しない。クライアントは引き続きOAuthのベストプラクティスに従い、与えられた操作に対して可能な限り限定されたscopeでTokenを要求するべきである（SHOULD）。これは「Best Current Practice for OAuth 2.0 Security」[RFC9700] のSection 2.3で説明されている。

7.3. Impersonation Attacks

クライアントは、保護対象リソース・メタデータ要求を行う際に、[RFC9525] に記述されるとおりTLS証明書検証を実行しなければならない（MUST）。サーバ証明書がresource identifier URLに対して有効であることを検証することは、中間者およびDNSベースの攻撃を防ぐ。これらの攻撃は、クライアントが攻撃者のResource Serverを使用するように騙される原因となり、正当な保護対象リソースになりすますことを可能にする。攻撃者がこれを達成できると、影響を受けたクライアントがアクセスできるリソースに対し、なりすましている保護対象リソースを用いてアクセスできてしまう。

攻撃者はまた、なりすます対象の保護対象リソースのresource identifier URLをresourceメタデータ・パラメータとして含みつつ、攻撃者が選んだ情報を含むメタデータ文書を公開することで、保護対象リソースになりすまそうとするかもしれない。クライアントがそれを受け入れた場合、なりすましが可能となる。これを防ぐため、クライアントは、メタデータ要求の接頭辞として使用しているresource identifier URLが、クライアントが受信した保護対象リソース・メタデータ文書中のresourceメタデータ・パラメータ値と正確に一致することを確認しなければならない（MUST）。これはSection 3.3で説明されている。

7.4. Audience-Restricted Access Tokens

クライアントが複数のResource Serverとやり取りすると期待している場合、クライアントは [RFC8707] を用いてaudience制限されたAccess Tokenを要求するべきであり（SHOULD）、Authorization Serverはaudience制限されたAccess Tokenをサポートするべきである（SHOULD）。

audience制限されたAccess Tokenがない場合、悪意あるResource Server（RS1）は、WWW-Authenticateヘッダを用いてクライアントに、正当なResource Server（RS2）で使用されるscopeを持つAccess Tokenを要求させることができるかもしれない。そしてクライアントがRS1へリクエストを送った後、RS1はそのAccess TokenをRS2で再利用できてしまうかもしれない。

この攻撃は本仕様によって明示的に可能になるものではなく、通常のOAuth 2.0配備でも起こり得るが、動的に構成されるクライアントの使用により、やや起こりやすくなる。したがって、本仕様の機能を使用する場合には、audience制限されたAccess TokenおよびResource Indicators [RFC8707] の使用が推奨される（RECOMMENDED）。

7.5. Publishing Metadata in a Standard Format

保護対象リソースに関する情報を標準形式で公開すると、正当なクライアントと攻撃者の双方にとって、保護対象リソースを利用しやすくなる。保護対象リソースがメタデータをアドホックに公開する場合であっても、本仕様が定義する標準形式で公開する場合であっても、この情報を利用して仕掛けられる可能性のある攻撃に対する防御は、同様に適用されるべきである。

7.6. Authorization Servers

保護対象リソースで使用する正当なauthorization serverの集合を列挙できるユースケースを支援するため、本仕様はauthorization_serversメタデータ・パラメータを定義し、それらを明示的に列挙できるようにする。なお、Authorization Serverで使用する正当な保護対象リソースの集合も列挙できる場合、application profileでこれらのリストを使用する際には、保護対象リソース・メタデータとAuthorization Serverメタデータのリスト同士を整合性のために相互検査するべきである。

保護対象リソースに対して使用すべき適切なAuthorization Serverの安全な決定は、すべてのユースケースにおいて本仕様のスコープ外である。本仕様は、クライアントが保護対象リソースに対して使用するのに適切なAuthorization Serverを決定する手段を持ち、かつクライアントが各保護対象リソースに対して正しいメタデータを使用していることを前提とする。実装者は、クライアントが不適切なAuthorization Serverを使用した場合、攻撃者が正当なAuthorization Serverへの中間者プロキシとして振る舞い、Authorization Serverまたはクライアントに検知されずに攻撃できる可能性があることを認識する必要がある。

（前の続き）

保護対象リソースに対して使用すべき適切なAuthorization Serverを決定する方法は、一般にapplication依存である。例えば、ある保護対象リソースは固定のAuthorization Serverまたは複数のAuthorization Server集合とともに利用されることがあり、それらの場所はアウト・オブ・バンドの仕組みにより既知である場合がある。あるいは、本仕様で説明するように、Authorization Serverの場所を保護対象リソースがメタデータ値として公開することもできる。さらに別の場合として、保護対象リソースで使用できるAuthorization Serverの集合は、管理上の操作や、信頼フレームワークに従うAuthorization Server集合の変化により動的に変わることがある。保護対象リソースとAuthorization Serverの適切な関連付けを決定するための他の多くの手段も可能である。

7.7. Server-Side Request Forgery (SSRF)

OAuthクライアントは、Resource Serverメタデータ中のissuerの値に基づいてAuthorization Serverメタデータを取得することが期待される。本仕様は、クライアントが事前知識を持たないRSおよびASと相互運用できるようにするため、悪意あるユーザや悪意あるResource ServerによるServer-Side Request Forgery (SSRF) 攻撃のリスクが開く。クライアントは、内部IPアドレス範囲へのリクエストをブロックするなど、SSRF攻撃に対する適切な予防策を講じるべきである（SHOULD）。追加の推奨は、Open Worldwide Application Security Project (OWASP) のSSRF Prevention Cheat Sheet [OWASP.SSRF] にある。

7.8. Phishing

本仕様は、所望のHTTPリソースがユーザにより選択されたURLで特定されるシナリオで配備される可能性がある。このリソースが悪意あるもの、または侵害されている場合、ユーザを誤誘導してアカウント資格情報を開示させたり、OAuthで制御される機能への望ましくないアクセスを認可させたりする可能性がある。このリスクは、OAuthユーザインターフェースに関するベストプラクティス（例えば、ユーザへの明確な通知、Authorization Serverのドメイン名の表示、オリジンに束縛されたフィッシング耐性のある認証器のサポート、パスワードマネージャの利用サポート、ドメイン評判などのヒューリスティック検査の適用）に従うことで軽減されるが、完全には排除されない。

7.9. Differences Between Unsigned and Signed Metadata

署名なしメタデータは、ホストされているサイトでのTLS利用により完全性が保護される。つまり、そのセキュリティは、[RFC9525] に記述されるX.509 (PKIX) を用いるInternet Public Key Infrastructureに依存する。署名付きメタデータはさらに、issuerにより付与されるJWS署名によって完全性が保護され、これはInternet PKIに依存しない。

署名なしメタデータを使用する場合、メタデータを発行する当事者は保護対象リソース自身であり、これはメタデータ中のresource値で表現される。一方、署名付きメタデータを使用する場合、メタデータを発行する当事者は、署名付きメタデータ中のiss（issuer）claimで表現される。署名付きメタデータを使用する場合、applicationは署名を行ったissuerに基づいて信頼判断を行える。これは署名なしメタデータでは利用できない情報である。これらの信頼判断がどのように行われるかは、本仕様のスコープ外である。

7.10. Metadata Caching

保護対象リソース・メタデータは、Section 3.1で規定されるHTTP GETリクエストにより取得される。通常のHTTPキャッシュ動作が適用され、GETリクエストは最新の内容ではなくキャッシュされた内容を取得する可能性がある。実装は、適切な期間にわたって取得したメタデータのキャッシュを可能にするために、[RFC9111] で定義されるmax-ageを伴うCache-Controlなど、HTTPキャッシュ指示子を利用するべきである。

8. IANA Considerations

値はSpecification Required [RFC8126] により登録される。登録要求は、2週間のレビュー期間を開始するために oauth-ext-review@ietf.org に送付するべきである。ただし、仕様の最終版の公開前に値の割り当てを可能にするため、指定された専門家（designated experts）は、仕様が完成し公開されることに満足できる場合、登録を承認してよい（MAY）。しかし、指定された専門家が判断するところにより、仕様が適時に完成・公開されない場合、指定された専門家はIANAに登録の撤回を要請してよい（MAY）。

レビュー用メーリングリストへ送信する登録要求では、適切な件名（例: "Request to register OAuth Protected Resource Metadata: example"）を用いるべきである。

レビュー期間内に、指定された専門家は登録要求を承認または却下し、この決定をレビュー用リストおよびIANAへ通知する。却下には説明を含め、適用可能であれば要求を成功させるための提案も含めるべきである。指定された専門家が応答しない場合、登録要求者はIANAへ連絡し、手続きをエスカレーションするべきである。

指定された専門家は、提案された登録をレビューする際、以下の基準を適用するべきである。すなわち、機能が一意であること（既存機能の重複でないこと）、単一のapplicationのためだけに用いられるのではなく一般に適用可能でありそうであること、明確でありレジストリの目的に適合していること、である。

IANAは、指定された専門家からのレジストリ更新のみを受け付けなければならず（MUST）、登録要求は全てレビュー用メーリングリストへ向けるよう、要請に対して案内するべきである。

登録判断について幅広い見識に基づくレビューを可能にするため、本仕様を利用する異なるapplicationの観点を代表できるよう、複数の指定された専門家が存在することが望ましい。登録が特定の専門家にとって利益相反と見なされ得る場合、その専門家は他の専門家の判断に従うべきである。

メーリングリストは、登録要求の公的レビューを可能にするために使用される。これにより、指定された専門家と、他の関心ある当事者の双方が、提案された登録に対するフィードバックを提供できる。指定された専門家は、最終版仕様の公開前に値を割り当ててよい（MAY）。これにより、著者は早期に指定された専門家の指針を得られ、特定された問題は最終版公開前に修正できる。

8.1. OAuth Protected Resource Metadata Registry

本仕様は、OAuth 2.0で保護されたリソース・メタデータ名のための「OAuth Protected Resource Metadata」レジストリを確立する。このレジストリは、保護対象リソース・メタデータ・パラメータと、それを定義する仕様への参照を記録する。

8.1.1. Registration Template

  • Metadata Name:\ 要求された名前（例: "resource"）。この名前は大文字小文字を区別する。指定された専門家が例外を認めるだけの説得力のある理由があると述べない限り、名前は、他の登録済み名と、大文字小文字を区別しない比較で一致してはならない。
  • Metadata Description:\ メタデータの簡潔な説明（例: "Resource identifier URL"）。
  • Change Controller:\ IETF Stream RFCの場合は「IETF」と記載する。それ以外の場合は責任主体の名称を記載する。その他の詳細（例: 郵送先住所、メールアドレス、ホームページURI）を含めてもよい（MAY）。
  • Specification Document(s):\ パラメータを規定する文書（または文書群）への参照。望ましくは、その文書のコピーを取得するために利用できるURIを含める。関連するSectionの指示を含めてもよいが、必須ではない。

8.1.2. Initial Registry Contents

  • Metadata Name: resource\ Metadata Description: Protected resource's resource identifier URL\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: authorization_servers\ Metadata Description: JSON array containing a list of OAuth authorization server issuer identifiers\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: jwks_uri\ Metadata Description: URL of the protected resource's JWK Set document\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: 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\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: bearer_methods_supported\ Metadata Description: JSON array containing a list of the OAuth 2.0 bearer token presentation methods that this protected resource supports\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: resource_signing_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\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: resource_name\ Metadata Description: Human-readable name of the protected resource\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: 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\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: 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\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: resource_tos_uri\ Metadata Description: URL of a page containing human-readable information about the protected resource's terms of service\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: tls_client_certificate_bound_access_tokens\ Metadata Description: Boolean value indicating protected resource support for mutual-TLS client certificate-bound access tokens\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: 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\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: dpop_signing_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\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: dpop_bound_access_tokens_required\ Metadata Description: Boolean value specifying whether the protected resource always requires the use of DPoP-bound access tokens\ Change Controller: IETF\ Specification Document(s): Section 2 of RFC 9728
  • Metadata Name: signed_metadata\ Metadata Description: Signed JWT containing metadata parameters about the protected resource as claims\ Change Controller: IETF\ Specification Document(s): Section 2.2 of RFC 9728

8.2. OAuth Authorization Server Metadata Registry

IANAは、「OAuth 2.0 Authorization Server Metadata」[RFC8414] により確立される「OAuth Authorization Server Metadata」レジストリに、以下のAuthorization Serverメタデータ・パラメータを登録した。

8.2.1. Registry Contents

  • Metadata Name: protected_resources\ Metadata Description: JSON array containing a list of resource identifiers for OAuth protected resources\ Change Controller: IETF\ Specification Document(s): Section 4 of RFC 9728

8.3. Well-Known URIs Registry

本仕様は、Section 3で定義されるwell-known URIを、「Well-Known URIs」レジストリ [IANA.well-known] に登録する。

8.3.1. Registry Contents

  • URI Suffix: oauth-protected-resource\ Reference: Section 3 of RFC 9728\ Status: permanent\ Change Controller: IETF\ Related Information: (none)

9. References

9.1. Normative References

  • [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.
  • [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.
  • [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.

9.2. Informative References

  • [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.

Acknowledgements

本仕様の著者は、IETF 115のOAuthおよびHTTP API Working Group会合の参加者、ならびにその後のOAuth Working Group会合の参加者による、本仕様への意見に感謝する。加えて、本仕様への貢献に対し、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、Bo Wuに感謝する。

Authors' Addresses

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/