1. Introduction (はじめに)
1. Introduction (はじめに)
本ドキュメントは, pushed authorization request (PAR) エンドポイントを定義する. これにより OAuth [RFC6749] クライアントは認可リクエストのペイロードを認可サーバへ直接プッシュできる. 交換として request URI 値を受け取り, ユーザエージェントによる認可エンドポイントへの後続呼び出しで認可リクエストペイロードデータを参照するために用いる.
OAuth [RFC6749] では, 認可リクエストパラメータは通常ユーザエージェントのリダイレクトで URI クエリパラメータとして送られる. これは単純だが, 次のような課題も生じる.
-
暗号学的完全性および真正性の保護がない. 攻撃者は例えば要求するアクセスの scope を改ざんしたり, scope 値を変えて決済文脈をすり替えたりできる. プロトコル上の仕組みでクライアントや利用者が一部の変更を検知できる場合もあるが, プロセスの早い段階で改ざんを防ぐ方が堅牢である.
-
リクエストパラメータの機密性を保証する仕組みがない. 認可エンドポイントには HTTPS が必須だが, リクエストデータはユーザエージェントを平文で通過し, クエリ文字列は Web サーバログや Referer 経由で他サイトに不用意に漏える可能性がある. 認可リクエストに個人を特定できる情報や規制対象データが含まれる場合 (アイデンティティ, オープンバンキング等で起こりうる), その影響は大きくなりうる.
-
認可リクエスト URL は特に細かい認可データが必要なシナリオで非常に大きくなり, リクエスト処理エラーの原因になりうる.
JWT-Secured Authorization Request (JAR) [RFC9101] は, OAuth クライアントが認可リクエストパラメータを Request Object で包むことでこれらのセキュリティ課題に対処する. Request Object は署名され, オプションで暗号化された JSON Web Token (JWT) [RFC7519] である. サイズ制限に対処するため, JAR は Request Object 本体の代わりに参照を送る request_uri パラメータを導入する.
本ドキュメントは, 認可リクエストのペイロードを認可サーバへ直接プッシュし, 後続の認可リクエストで認可サーバ上で利用可能な request_uri 値と交換する相互運用可能な方法を提供し, JAR を補完する.
PAR は, 機密性と完全性が保護された認可リクエストをクライアントが簡単に得られる手段を与え, OAuth のセキュリティを高める. さらに高いセキュリティレベル, 特に暗号学的に確認できる否認防止を要するクライアントは, [RFC9101] で定義される JWT ベースの Request Object を PAR と併用できる.
PAR により認可サーバはユーザとの対話の前にクライアントを認証できる. 認可プロセスにおけるクライアント身元への信頼が高まることで, 認可サーバは不正なリクエストをより早い段階で拒否でき, クライアントの偽装や認可リクエストの改ざん・悪用の試みを防げる.
なお, ユーザエージェント経由で認可エンドポイントへの HTTP POST リクエストを用いる方法 ([RFC6749] の第 3.1 節および [OIDC] の第 3.1.2.1 節) も, 上記のリクエストサイズ制限への対処に使える. しかし [RFC6749] では任意であり, サポートされていても従来の Web アプリケーションには実用的だが, インストール型モバイルアプリでは極めて困難である. [RFC8252] に記載のとおり, それらのアプリはプラットフォーム固有 API でシステムブラウザに認可リクエスト URI を開かせる. モバイルアプリがブラウザを起動すると, 最初のリクエストは GET に制限される. 認可リクエストに POST を使うには, アプリがまず GET で自身が制御する URI を開き, 何らかの方法で大きな認可リクエストペイロードを渡し, 応答に認可サーバへのクロスサイトフォーム POST を開始する内容とスクリプトを含めねばならない. PAR はより単純で, 前述の追加のセキュリティ上の利点もある.
1.1. Introductory Example (導入例) および 1.2. Conventions and Terminology (表記規則と用語) を参照のこと.