2.1. Request (请求)

客户端将构成授权请求的参数直接发送到 PAR 端点. 典型参数集可能包括: client_id, response_type, redirect_uri, scope, state, code_challenge 与 code_challenge_method, 如下例所示. 然而, 推送式授权请求可以由适用于授权端点的任意参数组成, 包括 [RFC6749] 定义的所有适用扩展中的参数. request_uri 授权请求参数是例外, 不得提供.

请求还包含, 视具体客户端而定, 客户端认证所需的任何附加参数 (例如 client_secret 或 client_assertion 与 client_assertion_type). 此类参数定义并注册用于令牌端点, 但仅适用于客户端认证. 当它们出现在推送式授权请求中时, 仅用于客户端认证, 与授权请求本身无关. 与客户端认证无关的任意令牌端点参数对推送式授权请求没有已定义的含义. client_id 参数对授权请求与令牌端点请求具有相同语义; 作为必需的授权请求参数, 在推送式授权请求中同样必需.

客户端按 [RFC6749] 附录 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

授权服务器必须按如下方式处理请求:

以与令牌端点相同的方式认证客户端 ([RFC6749] 第 2.3 节).
若提供了 request_uri 授权请求参数, 则拒绝请求.
像校验发送到授权端点的授权请求一样校验推送的请求. 例如, 授权服务器检查重定向 URI 是否与为客户端配置的某一重定向 URI 匹配, 并检查客户端是否有权获得其所请求访问的 scope. 此类校验使授权服务器能够尽早拒绝未授权或欺诈性请求. 授权服务器在处理推送请求时若无法执行某些校验步骤, 可以省略它们; 然而, 此类检查必须在授权端点处理授权请求时执行.

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

2.1. Request (请求)​

2.1. Request (请求)