1.1. 導入例

従来の OAuth 2.0 では、クライアントは通常、 ユーザーエージェントに、認可サーバーの認可エンドポイントに対して次のような HTTP リクエストを 行わせることで認可リクエストを開始します（追加の改行とインデントは 表示上の目的のみです）:¶

 GET /authorize?response_type=code
  &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
 Host: as.example.com

代わりに、このようなリクエストは、 次の例に示すように、クライアントが PAR エンドポイントに POST リクエストを送ることで 認可サーバーに直接プッシュできます（追加の改行と空白は表示上の目的のみです）。 リクエストは認可サーバーに直接行われるため、クライアントは認証できます （たとえば、ここに示す JWT クライアントアサーションベースの認証を使用します）。¶

 POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 &response_type=code
 &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
 &client_assertion=eyJraWQiOiI0MiIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJDTE
  lFTlQxMjM0Iiwic3ViIjoiQ0xJRU5UMTIzNCIsImF1ZCI6Imh0dHBzOi8vc2VydmVyL
  mV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY4ODc4fQ.Igw8QrpAWRNPDGoWGRmJumLBM
  wbLjeIYwqWUu-ywgvvufl_0sQJftNs3bzjIrP0BV9rRG-3eI1Ksh0kQ1CwvzA

認可サーバーはリクエスト URI で応答します:¶

 HTTP/1.1 201 Created
 Cache-Control: no-cache, no-store
 Content-Type: application/json

 {
   "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
   "expires_in": 90
 }

クライアントはリクエスト URI 値を使用して、 ユーザーエージェントに認可サーバーの 認可エンドポイントへ次のような HTTP リクエストを行わせることで、その後の認可 リクエストを作成します（追加の改行とインデントは表示上の目的のみです）:¶

 GET /authorize?client_id=CLIENT1234
  &request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
 Host: as.example.com

1.2. 規約および 用語

本文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、 "MAY"、および "OPTIONAL" は、 ここに示すようにすべて大文字で記述されている場合に限り、 BCP 14 [RFC2119] [RFC8174] に 記載されているとおりに解釈されます。¶

本仕様では、「The OAuth 2.0 Authorization Framework」[RFC6749] で定義されている「アクセストークン」、 「認可サーバー」、「認可エンドポイント」、 「認可リクエスト」、「トークンエンドポイント」、 および 「クライアント」という用語を使用します。¶

2.1. リクエスト

クライアントは、認可リクエストを構成するパラメーターを直接 PAR エンドポイントに送信します。一般的なパラメーターセットには、次の例に示すように client_id、response_type、redirect_uri、 scope、state、 code_challenge、および code_challenge_method が含まれることがあります。 ただし、プッシュ型認可リクエストは、[RFC6749] で定義されたもの、および適用可能なすべての拡張を含め、 認可エンドポイントで使用可能な任意のパラメーターから構成できます。 request_uri 認可リクエストパラメーターは例外であり、 提供しては MUST NOT なりません。¶

リクエストには、対象のクライアントに応じて、 クライアント認証に必要な追加パラメーター（たとえば、client_secret または client_assertion と client_assertion_type）も含まれます。このようなパラメーターは、 トークンエンドポイントで使用するために定義および登録されていますが、クライアント 認証にのみ適用されます。プッシュ型認可リクエストに存在する場合、それらは クライアント認証にのみ使用され、認可リクエスト自体には関係しません。クライアント 認証に関係しないトークンエンドポイントパラメーターは、プッシュ型認可リクエストにおいて定義された意味を 持ちません。client_id パラメーターは、認可リクエストと トークンエンドポイントへのリクエストの両方で同じ意味論を持つよう定義されています。必須の 認可リクエストパラメーターであるため、プッシュ型認可リクエストでも同様に必須です。¶

クライアントは、 付録 B of [RFC6749] で説明されているように、 UTF-8 の文字エンコーディングを使用し、x-www-form-urlencoded で整形したパラメーターを含む HTTP POST リクエストのメッセージ本文を構築します。 該当する場合、クライアントはトークンエンドポイントリクエストの場合と同じ規則を使用して、 認証資格情報もリクエストヘッダーまたは リクエスト本文に追加します。¶

次の例でこれを示します（メッセージ 本文内の追加の改行は表示上の目的のみです）:¶

 POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
 &code_challenge_method=S256&scope=account-information
 &client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
 &client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi
  OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc
  2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh
  TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se
  f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K
  dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W
  yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE
  RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6
  GQ

認可サーバーは、リクエストを 次のように処理しなければ MUST なりません:¶

1. トークンエンドポイントと同じ方法でクライアントを認証する （第 2.3節 of [RFC6749]）。¶
2. request_uri 認可 リクエストパラメーターが提供されている場合、リクエストを拒否する。¶
3. プッシュされたリクエストを、認可エンドポイントに送信された 認可リクエストと同じように検証する。たとえば、認可サーバーは、 リダイレクト URI がクライアント用に設定されたリダイレクト URI のいずれかに一致するかどうかを確認し、 また、クライアントがアクセスを要求しているスコープについて認可されているかどうかも確認します。この 検証により、認可サーバーは不正または詐欺的なリクエストを 早期に拒否できます。認可サーバーは、プッシュされたリクエストを処理する際に 実行できない検証手順を MAY 省略できます。ただし、そのような確認は、 認可エンドポイントで認可リクエストを処理する際に MUST 実行しなければなりません。¶

認可サーバーは、認証資格情報を持つクライアントに対し、 プッシュ型認可リクエストごとに認可リクエスト単位のリダイレクト URI を設定することを MAY 許可できます。第2.4節でより詳しく説明されているように、これは、[RFC6749] とは異なり、本仕様が 実際の認可リクエストが行われる前に、認可サーバーがクライアントを認証し、 クライアントのリクエストを検証できるようにするため可能です。¶

2.2. 成功レスポンス

検証に成功した場合、サーバーはリクエスト URI を 生成し、201 HTTP ステータスコードとともにレスポンスで提供しなければ MUST なりません。 次のパラメーターは、[RFC8259] で定義された application/json メディアタイプを使用する HTTP レスポンスのメッセージ本文にトップレベルのメンバーとして含まれます。¶

request_uri

送信された 認可リクエストに対応するリクエスト URI。この URI は、その後の認可リクエストにおいて 対応するリクエストデータへの一度限りの参照です。認可処理が 認可リクエストデータを取得する方法は認可サーバーの裁量に委ねられ、 本仕様の範囲外です。この URI を介して認可リクエストデータを 他の当事者が利用できるようにする必要はありません。¶

expires_in

リクエスト URI の有効期間を 秒単位の正の整数として表す JSON 数値。リクエスト URI の有効期間は 認可サーバーの裁量に委ねられますが、通常は比較的短いものです（たとえば、 5 秒から 600 秒の間）。¶

request_uri 値の形式は 認可サーバーの裁量に委ねられますが、有効な値を予測または推測することが 計算上実行不可能となるよう、暗号学的に強力な疑似乱数アルゴリズムを使用して生成された 一部を含まなければ MUST なりません（詳細については 第 10.10節 of [RFC6749] を参照してください）。 認可サーバーは、対応する認可リクエストデータを参照する URI のランダム部分として <reference-value> を使用し、 urn:ietf:params:oauth:request_uri:<reference-value> の形式で request_uri 値を構築することが MAY できます。¶

request_uri 値は、 認可リクエストを送信したクライアントに結び付けられなければ MUST なりません。¶

次は、そのようなレスポンスの例です:¶

 HTTP/1.1 201 Created
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "request_uri":
    "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c",
  "expires_in": 60
 }

2.3. エラーレスポンス

認可サーバーは、第5.2節 of [RFC6749] でトークンエンドポイントからのエラーレスポンスについて 規定されているものと同じ形式で、その節または 第4.1.2.1節 of [RFC6749] にある適切なエラーコードを使用して エラーレスポンスを返します。第 4.1.2.1節 of [RFC6749] が、要求元クライアントへの エラーによる自動リダイレクトを禁止し、そのためエラーコードを定義していない場合 （たとえば、リダイレクト URI の欠落、無効、または不一致によりリクエストが失敗した場合）、 invalid_request エラーコードをデフォルトのエラーコードとして使用できます。 プッシュされた認可リクエストの初期処理にその拡張が関与する場合、 OAuth 拡張で定義されたエラーコードも使用できます。プッシュ型認可リクエストの 初期処理にはリソース所有者との対話が含まれないため、[OIDC] で定義される consent_required など、 ユーザーとの対話に関連するエラーコードは返されません。¶

認可サーバーまたはクライアントポリシーによって、 クライアントに署名済みリクエストオブジェクトの使用が要求される場合（[RFC9101], 第10.5節 を参照）、認可サーバーは 第3節で示された定義に準拠するリクエストのみを MUST 受け付け、その他のリクエストは HTTP ステータスコード 400 および エラーコード invalid_request で MUST 拒否しなければなりません。¶

上記に加えて、PAR エンドポイントは次の HTTP ステータスコードも使用できます:¶

405:

リクエストが POST メソッドを使用していない場合、認可サーバーは HTTP 405 (Method Not Allowed) ステータスコードで応答します。¶

413:

リクエストサイズが認可サーバーの 許容する上限を超えた場合、認可サーバーは HTTP 413 (Payload Too Large) ステータスコードで応答します。¶

429:

特定の期間内にクライアントから送信された リクエスト数が認可サーバーの許容数を超えた場合、 認可サーバーは HTTP 429 (Too Many Requests) ステータスコードで応答します。¶

次は PAR エンドポイントからのエラーレスポンスの例です:¶

 HTTP/1.1 400 Bad Request
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
   "error": "invalid_request",
   "error_description":
     "The redirect_uri is not valid for the given client"
 }

2.4. クライアント リダイレクト URI の管理

OAuth 2.0 [RFC6749] は、 特定の状況でクライアントが未登録の redirect_uri 値を使用すること、または 認可サーバーが、認可エンドポイントでクライアントから提示された redirect_uri 値に 独自の一致規則を適用することを許可しています。しかし、OAuth security BCP [OAUTH-SECURITY-TOPICS] および OAuth 2.1 仕様 [OAUTH-V2] は、認可サーバーが redirect_uri パラメーターを、特定のクライアントについて事前に設定された リダイレクト URI の集合と完全一致させることを要求しています。これは、クライアントなりすましの試みを 早期に検出するための手段であり、トークン漏えいおよびオープンリダイレクトを防止します。一方で、 リダイレクト URI は通常、クライアントポリシーの中で最も変動しやすい部分であるため、 クライアント管理がより煩雑になる可能性があります。¶

認可サーバーとの認証資格情報を確立済みのクライアントが PAR を使用する場合、完全一致要件は MAY 緩和できます。 これは、従来の認可リクエストとは異なり、認可サーバーが認可処理開始前に クライアントを認証し、正当なクライアントと対話していることを確認できるため可能です。 認可サーバーは、そのようなクライアントに対し、認可サーバーに事前登録されていない redirect_uri 値を指定することを MAY 許可できます。これによりクライアントの柔軟性が高まり （たとえば、実行時に認可サーバーごとに異なる redirect_uri 値を生成できるようになり）、 クライアント管理を簡素化できます。提供された redirect_uri 値に 制限を適用するかどうかは認可サーバーの裁量に委ねられます。たとえば、認可サーバーは 特定の URI プレフィックスを要求したり、実行時にクエリ パラメーターだけが変更されることを許可したり MAY できます。¶

7.1. リクエスト URI の推測

攻撃者は、有効なリクエスト URI 値を推測してリプレイし、 対応するクライアントになりすまそうとする可能性があります。 認可サーバーは、リクエスト URI のエントロピーについて JAR [RFC9101], 第 10.2節 の (d) 項で示されている考慮事項を考慮しなければ MUST なりません。¶

7.2. オープンリダイレクト

攻撃者は、認可コードを取得したりユーザーに対して他の攻撃を 実行したりするため、自身の制御下にあるサイトを指すリダイレクト URI を登録しようとする可能性があります。 認可サーバーは、認証済みクライアントからのプッシュ型認可リクエストに含まれる 新しいリダイレクト URI のみを受け付けなければ MUST なりません。¶

7.3. リクエストオブジェクトのリプレイ

攻撃者は、正当な 認可リクエストから取得したリクエスト URI をリプレイする可能性があります。このような攻撃に対処するため、 認可サーバーはリクエスト URI を一度限りの使用にするべきです SHOULD。¶

7.4. クライアントポリシーの変更

リクエストオブジェクトの登録と、 特定のリクエストオブジェクトを使用する 認可リクエストとの間に、クライアントポリシーが変更される可能性があります。そのため、 認可リクエストを処理する際、認可サーバーが リクエストパラメーターをクライアントポリシーと照合することが推奨されます。¶

7.5. リクエスト URI のすり替え

攻撃者は、あるリクエストからリクエスト URI を取得し、 それを別の認可リクエストに差し替える可能性があります。たとえば OpenID Connect のコンテキストでは、 攻撃者は、高い認証保証レベルを要求するリクエスト URI を、 より低い保証レベルを要求するものに置き換える可能性があります。クライアントは、 この攻撃を防止するため、プッシュされたリクエストオブジェクト内で PKCE [RFC7636]、一意の state パラメーター [RFC6749]、または OIDC の "nonce" パラメーター [OIDC] を使用するべきです SHOULD。¶

9.1. OAuth 認可サーバー メタデータ

IANA は、[RFC8414] によって設立された [IANA.OAuth.Parameters] の IANA "OAuth Authorization Server Metadata" レジストリに次の値を登録しました。¶

メタデータ名:

pushed_authorization_request_endpoint¶

メタデータの説明:

認可サーバーのプッシュ型 認可リクエストエンドポイントの URL。¶

変更管理者:

IESG¶

仕様文書:

RFC 9126 の 第5節¶

メタデータ名:

require_pushed_authorization_requests¶

メタデータの説明:

認可サーバーが PAR を介してのみ認可リクエストを受け付けるかどうかを示します。¶

変更管理者:

IESG¶

仕様文書:

RFC 9126 の 第5節¶

9.2. OAuth 動的クライアント 登録メタデータ

IANA は、[RFC7591] によって設立された [IANA.OAuth.Parameters] の IANA "OAuth Dynamic Client Registration Metadata" レジストリに次の値を登録しました。¶

クライアントメタデータ名:

require_pushed_authorization_requests¶

クライアントメタデータの説明:

クライアントが 認可リクエストを開始するために PAR を使用する必要があるかどうかを示します。¶

変更管理者:

IESG¶

仕様文書:

RFC 9126 の 第6節¶

9.3. OAuth URI 登録

IANA は、[RFC6755] によって 設立された [IANA.OAuth.Parameters] の "OAuth URI" レジストリに次の値を登録しました。¶

URN:

urn:ietf:params:oauth:request_uri:¶

共通名:

OAuth リクエスト URI 用の URN サブ名前空間。¶

変更管理者:

IESG¶

仕様文書:

RFC 9126 の 第2.2節¶