2.3. Error Response (エラーレスポンス)

2.3. Error Response (エラーレスポンス)

認可サーバは, [RFC6749] 第 5.2 節がトークンエンドポイントのエラーレスポンスに指定するのと同じ形式でエラーレスポンスを返し, そこまたは [RFC6749] 第 4.1.2.1 節の適切なエラーコードを用いる. [RFC6749] 第 4.1.2.1 節がリクエスト元クライアントへのエラーの自動リダイレクトを禁止しエラーコードを定義しない場合 (例: 欠落, 無効, 不一致のリダイレクト URI による失敗), 既定のエラーコードとして invalid_request を用いてよい. プッシュされた認可リクエストの初期処理に OAuth 拡張が関与する場合は, その拡張で定義されたエラーコードも用いてよい. プッシュされた認可リクエストの初期処理はリソースオーナーとの対話を含まないため, [OIDC] の consent_required のようなユーザ対話関連のエラーコードは返されない.

クライアントが署名付き Request Object の使用を認可サーバまたはクライアントポリシーにより要求される場合 ([RFC9101] 第 10.5 節), 認可サーバは第 3 節の定義に適合するリクエストのみ受け入れ, それ以外は 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"
}