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] で定義される 「access token」、「authorization server」、「authorization endpoint」、 「authorization request」、「token endpoint」、および「client」という用語を使用する。¶

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 パラメーターは、認可リクエストとトークンエンドポイントへの リクエストの両方において同じ意味で定義されている。必須の認可リクエストパラメーターとして、 プッシュ型認可リクエストでも同様に必須である。¶

クライアントは、[RFC6749] の Appendix B で説明されているように、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. トークンエンドポイントでの場合と同じ方法でクライアントを認証する （[RFC6749] の Section 2.3）。¶
2. request_uri 認可リクエストパラメーターが提供されている場合、 リクエストを拒否する。¶
3. プッシュされたリクエストを、認可エンドポイントへ送信された 認可リクエストと同様に検証する。たとえば、認可サーバーは、リダイレクト URI が クライアントに設定されたリダイレクト URI のいずれかと一致するかを確認し、また クライアントがアクセスを要求している scope について認可されているかも確認する。 この検証により、認可サーバーは不正または詐欺的なリクエストを早期に拒否できる。 認可サーバーは、プッシュされたリクエストを処理する際に実行できない検証ステップを 省略MAY する。ただし、そのような確認は、認可エンドポイントで認可リクエストを 処理する際に実行MUST される。¶

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

2.2. 成功レスポンス

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

request_uri

投稿された認可リクエストに対応する リクエスト URI。この URI は、後続の認可リクエストにおいてそれぞれのリクエストデータへの 単回使用の参照である。認可プロセスが認可リクエストデータを取得する方法は 認可サーバーの裁量に委ねられ、本仕様の範囲外である。この URI を介して認可リクエストデータを 他の当事者に利用可能にする必要はない。¶

expires_in

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

request_uri 値の形式は認可サーバーの裁量に委ねられるが、 有効な値を予測または推測することが計算上不可能となるよう、暗号学的に強い疑似乱数 アルゴリズムを使用して生成された部分を含めMUST る（詳細については [RFC6749] の Section 10.10 を参照）。認可サーバーは、<reference-value> を それぞれの認可リクエストデータを参照する URI のランダム部分として、 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. エラーレスポンス

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

認可サーバーまたはクライアントポリシー（[RFC9101], Section 10.5 を参照）のいずれかによって、クライアントが署名済み Request Object を使用する必要がある場合、認可サーバーは Section 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 する、または 実行時にクエリパラメーターのみが変化することを許可MAY する。¶

7.1. リクエスト URI の推測

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

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

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

7.3. Request Object のリプレイ

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

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

Request Object の保存と、特定の Request Object を使用する認可リクエストとの 間に、クライアントポリシーが変更される可能性がある。したがって、認可リクエストを処理する際に、 認可サーバーが request パラメーターをクライアントポリシーに照らして確認することが推奨される。¶

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

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

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

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

メタデータ名:

pushed_authorization_request_endpoint¶

メタデータ説明:

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

変更管理者:

IESG¶

仕様文書:

RFC 9126 の Section 5¶

メタデータ名:

require_pushed_authorization_requests¶

メタデータ説明:

認可サーバーが PAR 経由でのみ認可リクエストを 受け付けるかどうかを示す。¶

変更管理者:

IESG¶

仕様文書:

RFC 9126 の Section 5¶

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

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

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

require_pushed_authorization_requests¶

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

クライアントが認可リクエストの開始に PAR を使用することを要求されるかどうかを示す。¶

変更管理者:

IESG¶

仕様文書:

RFC 9126 の Section 6¶

9.3. OAuth URI 登録

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

URN:

urn:ietf:params:oauth:request_uri:¶

一般名:

OAuth Request URI の URN サブ名前空間。¶

変更管理者:

IESG¶

仕様文書:

RFC 9126 の Section 2.2¶