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

客户端可以改为通过 POST 请求将此类请求直接推送到授权服务器的 PAR 端点，如下面的 示例所示（额外的换行和空格仅用于显示目的）。 客户端可以进行认证（例如，如示例中所示使用基于 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 参数在授权请求和令牌端点请求中具有相同 语义；作为必需的授权请求参数，它同样也是推送授权请求中的必需参数。¶

客户端构造 HTTP POST 请求的消息体， 其中参数以 x-www-form-urlencoded 格式表示，并使用 UTF-8 字符编码，如 [RFC6749] 附录 B 所述。如适用，客户端还会按照与令牌端点请求相同的规则， 将其认证凭据添加到请求头或请求体中。¶

以下示例对此进行了说明（消息 体中的额外换行仅用于显示目的）：¶

 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] 第 2.3 节）。¶
2. 如果提供了 request_uri 授权 请求参数，则拒绝该请求。¶
3. 像验证发送到授权端点的授权请求一样， 验证该推送请求。例如，授权服务器检查 重定向 URI 是否匹配为客户端配置的重定向 URI 之一，并且还检查 该客户端是否被授权访问其所请求的 scope。 这种验证允许授权服务器尽早拒绝未授权或欺诈性请求。 授权服务器 MAY 省略其在 处理推送请求时无法执行的验证步骤；然而，这些检查随后 MUST 在授权端点处理授权请求时执行。¶

授权服务器 MAY 允许具有 认证凭据的客户端在每个推送授权请求中建立每授权请求的重定向 URI。 如 第 2.4 节 更详细描述，这是可能的，因为与 [RFC6749] 不同，本规范使 授权服务器能够在实际授权请求执行之前认证客户端并验证客户端请求。¶

2.2. 成功响应

如果验证成功，服务器 MUST 生成一个请求 URI，并在响应中以 201 HTTP 状态码提供它。 以下参数作为顶层成员包含在 HTTP 响应的消息体中，使用 [RFC8259] 所定义的 application/json 媒体类型。¶

request_uri

与已提交的 授权请求对应的请求 URI。该 URI 是后续授权请求中相应请求 数据的单次使用引用。授权流程获取 授权请求数据的方式由授权服务器自行决定，并不在 本规范范围内。无需通过此 URI 将授权请求数据 提供给其他方。¶

expires_in

一个 JSON 数字，表示 请求 URI 的生存期，以秒为单位的正整数。请求 URI 生存期由 授权服务器自行决定，但通常会相对较短（例如，在 5 到 600 秒之间）。¶

request_uri 值的格式由 授权服务器自行决定，但它 MUST 包含某个使用 密码学强伪随机算法生成的部分，使得预测或猜测有效值在计算上不可行 （具体细节见 [RFC6749] 第 10.10 节）。授权服务器 MAY 使用 urn:ietf:params:oauth:request_uri:<reference-value> 形式构造 request_uri 值，其中 <reference-value> 是 URI 的随机部分，用来引用 相应的授权请求数据。¶

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] 第 5.2 节 中为令牌端点错误响应指定的格式相同，使用其中适当的错误代码 或 [RFC6749] 第 4.1.2.1 节 中的错误代码。在那些 [RFC6749] 第 4.1.2.1 节 禁止使用错误自动重定向回请求客户端， 因而没有定义错误代码的情况下（例如，当请求因缺失、无效或不匹配的 重定向 URI 而失败时），可以使用 invalid_request 错误代码作为默认 错误代码。当某个 OAuth 扩展参与已推送的授权请求的 初始处理时，也可以使用该 OAuth 扩展定义的错误代码。由于 推送授权请求的初始处理不涉及资源所有者交互， 因此与用户交互相关的错误代码，例如 [OIDC] 中定义的 consent_required，绝不会返回。¶

如果客户端被授权服务器或客户端策略要求使用已签名的 Request Object（见 [RFC9101], 第 10.5 节），则授权服务器 MUST 仅接受符合 第 3 节 中给出定义的请求，并且 MUST 以 HTTP 状态码 400 和错误代码 invalid_request 拒绝任何其他请求。¶

除上述内容外，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 安全 BCP [OAUTH-SECURITY-TOPICS] 以及 OAuth 2.1 规范 [OAUTH-V2] 要求授权服务器将 redirect_uri 参数与先前为特定客户端建立的一组重定向 URI 进行精确匹配。这是早期检测客户端冒充尝试的一种手段， 并可防止令牌泄露和开放重定向。缺点是，这会使客户端管理更加 繁琐，因为重定向 URI 通常是客户端策略中最易变的部分。¶

对于已与授权服务器建立认证凭据的客户端， 使用 PAR 时 MAY 放宽精确匹配要求。 这是可能的，因为与传统授权请求不同， 授权服务器会在授权流程开始之前认证客户端，从而 确保它正在与合法客户端交互。授权服务器 MAY 允许此类客户端指定 先前未向授权服务器注册的 redirect_uri 值。这将给予客户端更大的 灵活性（例如，在运行时为每个授权服务器铸造不同的 redirect_uri 值）， 并可简化客户端管理。授权服务器可自行决定对所提供的 redirect_uri 值施加限制，例如，授权服务器 MAY 要求特定 URI 前缀，或只允许查询 参数在运行时变化。¶

7.1. 请求 URI 猜测

攻击者可能尝试猜测并重放有效的请求 URI 值，并 试图冒充相应客户端。 授权服务器 MUST 考虑 JAR [RFC9101], 第 10.2 节 中关于 request URI 熵的第（d）项考量。¶

7.2. 开放重定向

攻击者可能试图注册一个指向其控制站点的重定向 URI， 以获取授权码或对用户发起其他攻击。 授权服务器 MUST 只接受来自已认证客户端的 推送授权请求中的新重定向 URI。¶

7.3. 请求对象重放

攻击者可能重放从合法 授权请求中捕获的请求 URI。为应对此类攻击，授权服务器 SHOULD 使请求 URI 一次性使用。¶

7.4. 客户端策略变更

在提交 Request Object 与使用特定 Request Object 发起 授权请求之间，客户端策略可能发生变化。因此，建议 授权服务器在处理授权请求时根据客户端策略检查 request 参数。¶

7.5. 请求 URI 调换

攻击者可能从一个请求中捕获 request URI，然后将其替换到 另一个授权请求中。例如，在 OpenID Connect 语境下，攻击者 可能将请求高认证保证级别的 request URI 替换为 要求较低保证级别的 request URI。客户端 SHOULD 在 推送的 Request Object 中使用 PKCE [RFC7636]、 唯一的 state 参数 [RFC6749]， 或 OIDC “nonce”参数 [OIDC]， 以防止此攻击。¶

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 Request URI 的 URN 子命名空间。¶

变更控制方：

IESG¶

规范文档：

RFC 9126 的 第 2.2 节¶