メインコンテンツまでスキップ

2.1. Request (リクエスト)

2.1. Request (リクエスト)​

クライアントは認可リクエストを構成するパラメータを 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] 付録 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] 第 2.3 節).

  2. request_uri 認可リクエストパラメータが提供されていればリクエストを拒否する.

  3. 認可エンドポイントに送られた認可リクエストと同様にプッシュされたリクエストを検証する. 例えばリダイレクト URI がクライアントに設定されたいずれかと一致するか, 要求する scope に対してクライアントが認可されているかを確認する. この検証により未認可や不正なリクエストを早期に拒否できる. プッシュ処理時に実行できない検証手順は省略してもよい (MAY), ただしそのようなチェックは認可エンドポイントで認可リクエストを処理する際に実行しなければならない (MUST).

認可サーバは, 認証情報を持つクライアントに対し, 各プッシュされた認可リクエストごとに認可リクエスト単位のリダイレクト URI を設定することを許容してもよい (MAY). [RFC6749] とは異なり本仕様は実際の認可リクエストの前にクライアントを認証しクライアントリクエストを検証できるため, 第 2.4 節で詳述する.

に最終更新