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

4. Authorization Request (認可リクエスト)

4. Authorization Request (認可リクエスト)​

クライアントは認可サーバが返した request_uri 値を用いて, [RFC9101] に従い認可リクエストを構築する. 下の例では, クライアントがユーザエージェントに次の HTTP リクエストを送らせる様子を示す (表示のための改行とインデントのみ).

GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams
 %3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1
Host: as.example.com

認可リクエスト内容の一部 (例: code_challenge パラメータ値) は特定の認可リクエストに固有であるため, クライアントは request_uri 値を一度だけ用いなければならない (MUST). 認可サーバは request_uri を一回限りの使用として扱うべきである (SHOULD) が, ユーザがユーザエージェントを再読み込み/更新した結果の重複リクエストは許容してもよい (MAY). 期限切れの request_uri は無効として拒否しなければならない (MUST).

認可サーバは, プッシュされたリクエストに由来する認可リクエストを, 他の認可リクエストと同様に検証しなければならない (MUST). 当該リクエストがプッシュされたものであったこと, およびリクエストまたは認可サーバポリシーが省略した手順の結果に影響する形で変更されていないことを検証できる場合, プッシュ時に実施済みの検証手順は省略してもよい (MAY).

認可サーバポリシーは, グローバルまたはクライアント単位で, クライアントが認可リクエストデータを渡す唯一の手段を PAR に限定してもよい (MAY). この場合, 認可サーバは PAR エンドポイントから得た値を持たない request_uri パラメータによる認可エンドポイントへのリクエストを, invalid_request エラーコードで処理を拒否する.

注: 認可サーバとクライアントは, 第 5 節および第 6 節で定義されるメタデータを用いて望ましい動作を示してもよい (MAY).

に最終更新