この記事では『OAuth 2.0 Pushed Authorization Requests』（通称 PAR）を図を用いて説明します。（英語版はこちら）
2021 年 9 月 16 日追記：PAR が RFC 9126 になりました。
クライアントアプリケーションと認可サーバーがあります。
クライアントアプリケーションは複雑な認可リクエストを抱えています。
もしも認可サーバーが『OAuth 2.0 Pushed Authorization Requests』（通称 PAR）をサポートしているなら、サーバーは『Pushed Authorization Request Endpoint』を公開しています。
クライアントアプリケーションは、Pushed Authorization Request Endpoint で複雑な認可リクエストを認可サーバーに登録します。
応答として、登録された認可リクエストを表す『Request URI』が発行されます。
クライアントアプリケーションは Web ブラウザを介して認可サーバーの認可エンドポイントに認可リクエストを送信します。クライアントは複雑な認可リクエストを送る必要はありません。かわりに、発行された Request URI を request_uri リクエストパラメーターの値として送るだけで十分です。（『RFC 9101 JWT-Secured Authorization Request』（通称 JAR）が敢えて破った後方互換性を大事に思うなら、client_id や response_type などの必須リクエストパラメーター群も添えて）
応答として、認可コード、アクセストークン、ID トークンなどが発行されます。下図では認可コードが発行されています。これは、認可リクエストの response_type リクエストパラメーターが code を含んでいる場合に起こります。トークン群とフロー群の関係については『OpenID Connect 全フロー解説』を参照してください。
クライアントアプリケーションはいつものように認可コードを添えて認可サーバーのトークンエンドポイントにトークンリクエストを送信します。
応答として、アクセストークンおよび条件により ID トークンが発行されます。
まとめのフルカラーダイアグラム。
新しいユースケースや要望に対応するため、新しい仕様群の開発が続いています。そのような仕様群の中には、認可リクエストを大きくするものがあります。例えば、『OAuth 2.0 Rich Authorization Requests』（RAR）は複雑な JSON 構造を持つ authorization_details リクエストパラメーターを追加し、『OpenID Connect for Identity Assurance 1.0』(IDA）（私の記事：『Identity Assurance - eKYC 時代の OpenID Connect）は claims リクエストパラメーター（OIDC Core 1.0, Section 5.5）の値に、これもまた複雑な JSON 構造を持つ verified_claims を挿入しました。
この記事で取り上げた『OAuth 2.0 Pushed Authorization Requests』（PAR）は、クライアントアプリケーションが大きな認可リクエストを Web ブラウザを介して送る必要がなくなるよう開発されました。加えて、PAR により他の利点ももたらされます。より多くの情報については、PAR 仕様自体や、仕様の著者である Torsten Lodderstedt 氏の記事群（例えば『Pushed Authorization Requests Draft adopted by OAuth Working Group』等）を参照してください。
私の会社の製品である Authlete（オースリート）は、バージョン 2.2 以降で PAR、RAR、IDA をサポートしています（スペックシート）。これらの新しい仕様群を試されたい方は、コンタクトフォームやメール（sales@authlete.com）でお問い合わせください。