OAuth 2.0 Pushed Authorization Requests

Abstract

概要

This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.

本文書は pushed authorization request (PAR) エンドポイントを定義する。このエンドポイントにより、クライアントは OAuth 2.0 認可リクエストのペイロードを直接リクエストによって認可サーバーにプッシュでき、その後の認可エンドポイントへの呼び出しでそのデータへの参照として使うリクエスト URI を受け取ることができる。

1.Introduction

1.はじめに

This document defines the pushed authorization request (PAR) endpoint, which enables an OAuth [RFC6749] client to push the payload of an authorization request directly to the authorization server. A request URI value is received in exchange; it is used as reference to the authorization request payload data in a subsequent call to the authorization endpoint via the user agent.

本文書は pushed authorization request (PAR) エンドポイントを定義する。これにより OAuth [RFC6749] クライアントは認可リクエストのペイロードを認可サーバーに直接プッシュできる。引き換えにリクエスト URI の値を受け取り、その値はユーザーエージェント経由のその後の認可エンドポイントへの呼び出しにおいて、認可リクエストのペイロードデータへの参照として使われる。

In OAuth [RFC6749], authorization request parameters are typically sent as URI query parameters via redirection in the user agent. This is simple but also yields challenges:

OAuth [RFC6749] では、認可リクエストのパラメーターは通常、ユーザーエージェントでのリダイレクトを介して URI クエリパラメーターとして送られる。これは単純であるが、次のような課題も生む:

* There is no cryptographic integrity and authenticity protection. An attacker could, for example, modify the scope of access requested or swap the context of a payment transaction by changing scope values. Although protocol facilities exist to enable clients or users to detect some such changes, preventing modifications early in the process is a more robust solution.

* 暗号学的な完全性と真正性の保護がない。攻撃者は、例えば要求するアクセスのスコープを改変したり、スコープの値を変えることで決済トランザクションの文脈をすり替えたりできる。クライアントやユーザーがそのような変更の一部を検知できるプロトコル上の仕組みは存在するが、プロセスの早い段階で改変を防ぐ方がより堅牢な解決策である。

* There is no mechanism to ensure confidentiality of the request parameters. Although HTTPS is required for the authorization endpoint, the request data passes through the user agent in the clear, and query string data can inadvertently leak to web server logs and to other sites via the referrer. The impact of such leakage can be significant, if personally identifiable information or other regulated data is sent in the authorization request (which might well be the case in identity, open banking, and similar scenarios).

* リクエストパラメーターの機密性を保証する仕組みがない。認可エンドポイントには HTTPS が要求されるものの、リクエストデータはユーザーエージェントを平文で通過し、クエリ文字列のデータは Web サーバーのログや、リファラーを介して他のサイトに意図せず漏洩しうる。認可リクエストに個人を識別できる情報やその他の規制対象データが含まれる場合 (アイデンティティ、オープンバンキングなどのシナリオでは十分ありうる)、そのような漏洩の影響は重大になりうる。

* Authorization request URLs can become quite large, especially in scenarios requiring fine-grained authorization data, which might cause errors in request processing.

* 認可リクエストの URL は、特にきめ細かな認可データを必要とするシナリオではかなり大きくなることがあり、リクエスト処理でエラーを引き起こすおそれがある。

JWT-Secured Authorization Request (JAR) [RFC9101] provides solutions for the security challenges by allowing OAuth clients to wrap authorization request parameters in a Request Object, which is a signed and optionally encrypted JSON Web Token (JWT) [RFC7519]. In order to cope with the size restrictions, JAR introduces the "request_uri" parameter that allows clients to send a reference to a Request Object instead of the Request Object itself.

JWT-Secured Authorization Request (JAR) [RFC9101] は、OAuth クライアントが認可リクエストのパラメーターを Request Object、すなわち署名され任意で暗号化された JSON Web Token (JWT) [RFC7519] に包むことを可能にし、セキュリティ上の課題への解決策を提供する。サイズの制約に対処するため、JAR は "request_uri" パラメーターを導入し、クライアントが Request Object そのものの代わりに Request Object への参照を送れるようにしている。

This document complements JAR by providing an interoperable way to push the payload of an authorization request directly to the authorization server in exchange for a "request_uri" value usable at the authorization server in a subsequent authorization request.

本文書は JAR を補完し、認可リクエストのペイロードを認可サーバーに直接プッシュして、その後の認可リクエストにおいて認可サーバーで使える "request_uri" の値と引き換える、相互運用可能な方法を提供する。

PAR fosters OAuth security by providing clients a simple means for a confidential and integrity-protected authorization request. Clients requiring an even higher security level, especially cryptographically confirmed non-repudiation, are able to use JWT-based Request Objects as defined by [RFC9101] in conjunction with PAR.

PAR は、機密性と完全性が保護された認可リクエストのための簡潔な手段をクライアントに提供することで、OAuth のセキュリティを促進する。さらに高いセキュリティレベル、特に暗号学的に確認された否認防止を必要とするクライアントは、[RFC9101] で定義される JWT ベースの Request Object を PAR と組み合わせて使うことができる。

PAR allows the authorization server to authenticate the client before any user interaction happens. The increased confidence in the identity of the client during the authorization process allows the authorization server to refuse illegitimate requests much earlier in the process, which can prevent attempts to spoof clients or otherwise tamper with or misuse an authorization request.

PAR により、認可サーバーはユーザーとのやり取りが発生する前にクライアントを認証できる。認可プロセス中のクライアントのアイデンティティに対する確信が高まることで、認可サーバーは不正なリクエストをプロセスのはるかに早い段階で拒否でき、クライアントのなりすましや、認可リクエストの改ざん・悪用の試みを防ぐことができる。

Note that HTTP "POST" requests to the authorization endpoint via the user agent, as described in Section 3.1 of [RFC6749] and Section 3.1.2.1 of [OIDC], could also be used to cope with the request size limitations described above. However, it's only optional per [RFC6749], and, even when supported, it is a viable option for conventional web applications but is prohibitively difficult to use with installed mobile applications. As described in [RFC8252], those apps use platform-specific APIs to open the authorization request URI in the system browser. When a mobile app launches a browser, however, the resultant initial request is constrained to use the "GET" method. Using "POST" for the authorization request would require the app to first direct the browser to open a URI that the app controls via "GET" while somehow conveying the sizable authorization request payload and then having the resultant response contain the content and script to initiate a cross-site form "POST" towards the authorization server. PAR is simpler to use and has additional security benefits, as described above.

[RFC6749] の 3.1 節および [OIDC] の 3.1.2.1 節に記述されている、ユーザーエージェント経由での認可エンドポイントへの HTTP "POST" リクエストも、上記のリクエストサイズの制約に対処するために使えることに注意されたい。しかし、これは [RFC6749] では任意 (optional) に過ぎず、サポートされている場合でも、従来型の Web アプリケーションにとっては現実的な選択肢であるものの、インストール型のモバイルアプリケーションでは使うのが極めて困難である。[RFC8252] に記述されているように、そのようなアプリはプラットフォーム固有の API を使ってシステムブラウザーで認可リクエスト URI を開く。しかし、モバイルアプリがブラウザーを起動した場合、その結果として生じる最初のリクエストは "GET" メソッドを使うことに制約される。認可リクエストに "POST" を使うには、アプリがまずブラウザーに対して、アプリが制御する URI を "GET" で開かせ、その際に何らかの方法で大きな認可リクエストのペイロードを渡し、その応答に認可サーバーへのクロスサイトフォーム "POST" を開始するコンテンツとスクリプトを含める必要がある。PAR は使うのがより簡単であり、上述のとおりセキュリティ上の利点も加わる。

1.1.Introductory Example

1.1.導入例

In conventional OAuth 2.0, a client typically initiates an authorization request by directing the user agent to make an HTTP request like the following to the authorization server's authorization endpoint (extra line breaks and indentation for display purposes only):

従来の OAuth 2.0 では、クライアントは通常、ユーザーエージェントに次のような HTTP リクエストを認可サーバーの認可エンドポイントに対して行わせることで認可リクエストを開始する (余分な改行とインデントは表示目的のみ):

Such a request could instead be pushed directly to the authorization server by the client with a "POST" request to the PAR endpoint as illustrated in the following example (extra line breaks and spaces for display purposes only). The client can authenticate (e.g., using JWT client assertion-based authentication as shown) because the request is made directly to the authorization server.

このようなリクエストは、代わりに次の例に示すように、クライアントが PAR エンドポイントへの "POST" リクエストで認可サーバーに直接プッシュすることができる (余分な改行とスペースは表示目的のみ)。リクエストは認可サーバーに直接行われるため、クライアントは (例に示すように JWT クライアントアサーションに基づく認証などを使って) 認証を行うことができる。

The authorization server responds with a request URI:

認可サーバーはリクエスト URI で応答する:

The client uses the request URI value to create the subsequent authorization request by directing the user agent to make an HTTP request to the authorization server's authorization endpoint like the following (extra line breaks and indentation for display purposes only):

クライアントはリクエスト URI の値を使って、ユーザーエージェントに次のような HTTP リクエストを認可サーバーの認可エンドポイントに対して行わせることで、その後の認可リクエストを作成する (余分な改行とインデントは表示目的のみ):

1.2.Conventions and Terminology

1.2.表記規約と用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文書中のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、ここに示すようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈される。

This specification uses the terms "access token", "authorization server", "authorization endpoint", "authorization request", "token endpoint", and "client" defined by "The OAuth 2.0 Authorization Framework" [RFC6749].

本仕様は、"The OAuth 2.0 Authorization Framework" [RFC6749] で定義される用語「アクセストークン」、「認可サーバー」、「認可エンドポイント」、「認可リクエスト」、「トークンエンドポイント」、および「クライアント」を使用する。

2.Pushed Authorization Request Endpoint

2.Pushed Authorization Request エンドポイント

The pushed authorization request endpoint is an HTTP API at the authorization server that accepts HTTP "POST" requests with parameters in the HTTP request message body using the "application/x- www-form-urlencoded" format. This format has a character encoding of UTF-8, as described in Appendix B of [RFC6749]. The PAR endpoint URL MUST use the "https" scheme.

pushed authorization request エンドポイントは認可サーバーにある HTTP API であり、HTTP リクエストメッセージボディに "application/x-www-form-urlencoded" 形式でパラメーターを含む HTTP "POST" リクエストを受け付ける。この形式の文字エンコーディングは、[RFC6749] の付録 B に記述されているとおり UTF-8 である。PAR エンドポイントの URL は "https" スキームを使わなければならない (MUST)。

Authorization servers supporting PAR SHOULD include the URL of their pushed authorization request endpoint in their authorization server metadata document [RFC8414] using the "pushed_authorization_request_endpoint" parameter as defined in Section 5.

PAR をサポートする認可サーバーは、5 節で定義される "pushed_authorization_request_endpoint" パラメーターを使って、認可サーバーメタデータ文書 [RFC8414] に pushed authorization request エンドポイントの URL を含めるべきである (SHOULD)。

The endpoint accepts the authorization request parameters defined in [RFC6749] for the authorization endpoint as well as all applicable extensions defined for the authorization endpoint. Some examples of such extensions include Proof Key for Code Exchange (PKCE) [RFC7636], Resource Indicators [RFC8707], and OpenID Connect (OIDC) [OIDC]. The endpoint MAY also support sending the set of authorization request parameters as a Request Object according to [RFC9101] and Section 3 of this document.

このエンドポイントは、[RFC6749] で認可エンドポイント向けに定義された認可リクエストパラメーターに加えて、認可エンドポイント向けに定義された適用可能なすべての拡張を受け付ける。そのような拡張の例には、Proof Key for Code Exchange (PKCE) [RFC7636]、Resource Indicators [RFC8707]、および OpenID Connect (OIDC) [OIDC] がある。このエンドポイントは、[RFC9101] および本文書の 3 節に従って、認可リクエストパラメーターの集合を Request Object として送ることもサポートしてよい (MAY)。

The rules for client authentication as defined in [RFC6749] for token endpoint requests, including the applicable authentication methods, apply for the PAR endpoint as well. If applicable, the "token_endpoint_auth_method" client metadata parameter [RFC7591] indicates the registered authentication method for the client to use when making direct requests to the authorization server, including requests to the PAR endpoint. Similarly, the "token_endpoint_auth_methods_supported" authorization server metadata [RFC8414] parameter lists client authentication methods supported by the authorization server when accepting direct requests from clients, including requests to the PAR endpoint.

[RFC6749] でトークンエンドポイントのリクエスト向けに定義されたクライアント認証の規則は、適用可能な認証方式を含めて、PAR エンドポイントにも同様に適用される。該当する場合、"token_endpoint_auth_method" クライアントメタデータパラメーター [RFC7591] は、PAR エンドポイントへのリクエストを含め、クライアントが認可サーバーへ直接リクエストを行う際に使う登録済みの認証方式を示す。同様に、"token_endpoint_auth_methods_supported" 認可サーバーメタデータパラメーター [RFC8414] は、PAR エンドポイントへのリクエストを含め、認可サーバーがクライアントからの直接リクエストを受け付ける際にサポートするクライアント認証方式を列挙する。

Due to historical reasons, there is potential ambiguity regarding the appropriate audience value to use when employing JWT client assertion-based authentication (defined in Section 2.2 of [RFC7523] with "private_key_jwt" or "client_secret_jwt" authentication method names per Section 9 of [OIDC]). To address that ambiguity, the issuer identifier URL of the authorization server according to [RFC8414] SHOULD be used as the value of the audience. In order to facilitate interoperability, the authorization server MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.

歴史的な理由により、JWT クライアントアサーションに基づく認証 ([RFC7523] の 2.2 節で定義され、[OIDC] の 9 節に従って認証方式名 "private_key_jwt" または "client_secret_jwt" で呼ばれる) を用いる際に使うべき適切なオーディエンスの値に関しては、潜在的な曖昧さがある。この曖昧さに対処するため、[RFC8414] に従った認可サーバーの発行者識別子 URL をオーディエンスの値として使うべきである (SHOULD)。相互運用性を促進するため、認可サーバーは、その発行者識別子、トークンエンドポイント URL、または pushed authorization request エンドポイント URL を、自身を意図されたオーディエンスとして識別する値として受け入れなければならない (MUST)。

2.1.Request

2.1.リクエスト

A client sends the parameters that comprise an authorization request directly to the PAR endpoint. A typical parameter set might include: "client_id", "response_type", "redirect_uri", "scope", "state", "code_challenge", and "code_challenge_method" as shown in the example below. However, the pushed authorization request can be composed of any of the parameters applicable for use at the authorization endpoint, including those defined in [RFC6749] as well as all applicable extensions. The "request_uri" authorization request parameter is one exception, and it MUST NOT be provided.

クライアントは、認可リクエストを構成するパラメーターを PAR エンドポイントに直接送る。典型的なパラメーターの集合には、以下の例に示すように "client_id"、"response_type"、"redirect_uri"、"scope"、"state"、"code_challenge"、および "code_challenge_method" が含まれうる。しかし、pushed authorization request は、[RFC6749] で定義されたものと適用可能なすべての拡張を含め、認可エンドポイントで使用可能な任意のパラメーターから構成できる。"request_uri" 認可リクエストパラメーターは唯一の例外であり、これを提供してはならない (MUST NOT)。

The request also includes, as appropriate for the given client, any additional parameters necessary for client authentication (e.g., "client_secret" or "client_assertion" and "client_assertion_type"). Such parameters are defined and registered for use at the token endpoint but are applicable only for client authentication. When present in a pushed authorization request, they are relied upon only for client authentication and are not germane to the authorization request itself. Any token endpoint parameters that are not related to client authentication have no defined meaning for a pushed authorization request. The "client_id" parameter is defined with the same semantics for both authorization requests and requests to the token endpoint; as a required authorization request parameter, it is similarly required in a pushed authorization request.

このリクエストには、当該クライアントに応じて、クライアント認証に必要な追加のパラメーター (例えば "client_secret"、または "client_assertion" と "client_assertion_type") も含まれる。これらのパラメーターはトークンエンドポイントでの使用のために定義・登録されているが、クライアント認証のみに適用される。pushed authorization request に存在する場合、それらはクライアント認証のためにのみ依拠され、認可リクエスト自体には関係しない。クライアント認証に関係しないトークンエンドポイントのパラメーターは、pushed authorization request において定義された意味を持たない。"client_id" パラメーターは、認可リクエストとトークンエンドポイントへのリクエストの両方で同じ意味論で定義されている。認可リクエストの必須パラメーターであるため、pushed authorization request においても同様に必須である。

The client constructs the message body of an HTTP "POST" request with parameters formatted with "x-www-form-urlencoded" using a character encoding of UTF-8, as described in Appendix B of [RFC6749]. If applicable, the client also adds its authentication credentials to the request header or the request body using the same rules as for token endpoint requests.

クライアントは、[RFC6749] の付録 B に記述されているとおり、UTF-8 の文字エンコーディングを用いて "x-www-form-urlencoded" で整形したパラメーターで HTTP "POST" リクエストのメッセージボディを構築する。該当する場合、クライアントはトークンエンドポイントのリクエストと同じ規則を使って、認証クレデンシャルをリクエストヘッダーまたはリクエストボディに追加する。

This is illustrated by the following example (extra line breaks in the message body for display purposes only):

これを次の例に示す (メッセージボディ中の余分な改行は表示目的のみ):

The authorization server MUST process the request as follows:

認可サーバーはリクエストを次のように処理しなければならない (MUST):

1. Authenticate the client in the same way as at the token endpoint (Section 2.3 of [RFC6749]).

1. トークンエンドポイントと同じ方法でクライアントを認証する ([RFC6749] の 2.3 節)。

2. Reject the request if the "request_uri" authorization request parameter is provided.

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

3. Validate the pushed request as it would an authorization request sent to the authorization endpoint. For example, the authorization server checks whether the redirect URI matches one of the redirect URIs configured for the client and also checks whether the client is authorized for the scope for which it is requesting access. This validation allows the authorization server to refuse unauthorized or fraudulent requests early. The authorization server MAY omit validation steps that it is unable to perform when processing the pushed request; however, such checks MUST then be performed when processing the authorization request at the authorization endpoint.

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

The authorization server MAY allow clients with authentication credentials to establish per-authorization-request redirect URIs with every pushed authorization request. Described in more detail in Section 2.4, this is possible since, in contrast to [RFC6749], this specification gives the authorization server the ability to authenticate clients and validate client requests before the actual authorization request is performed.

認可サーバーは、認証クレデンシャルを持つクライアントに対して、pushed authorization request ごとに認可リクエスト単位のリダイレクト URI を確立することを許可してよい (MAY)。2.4 節でより詳しく記述するように、これが可能なのは、[RFC6749] とは対照的に、本仕様が実際の認可リクエストが行われる前にクライアントを認証しクライアントのリクエストを検証する能力を認可サーバーに与えるからである。

2.2.Successful Response

2.2.成功応答

If the verification is successful, the server MUST generate a request URI and provide it in the response with a "201" HTTP status code. The following parameters are included as top-level members in the message body of the HTTP response using the "application/json" media type as defined by [RFC8259].

検証が成功した場合、サーバーはリクエスト URI を生成し、HTTP ステータスコード "201" とともに応答で提供しなければならない (MUST)。次のパラメーターが、[RFC8259] で定義される "application/json" メディアタイプを用いた HTTP 応答のメッセージボディにトップレベルのメンバーとして含まれる。

request_uri The request URI corresponding to the authorization request posted. This URI is a single-use reference to the respective request data in the subsequent authorization request. The way the authorization process obtains the authorization request data is at the discretion of the authorization server and is out of scope of this specification. There is no need to make the authorization request data available to other parties via this URI.

request_uri 投稿された認可リクエストに対応するリクエスト URI。この URI は、その後の認可リクエストにおける該当リクエストデータへの一回限りの参照である。認可プロセスが認可リクエストデータを取得する方法は認可サーバーの裁量であり、本仕様の範囲外である。この URI を介して認可リクエストデータを他の当事者に利用可能にする必要はない。

expires_in A JSON number that represents the lifetime of the request URI in seconds as a positive integer. The request URI lifetime is at the discretion of the authorization server but will typically be relatively short (e.g., between 5 and 600 seconds).

expires_in リクエスト URI の有効期間を秒単位の正の整数で表す JSON 数値。リクエスト URI の有効期間は認可サーバーの裁量であるが、通常は比較的短い (例えば 5 秒から 600 秒の間)。

The format of the "request_uri" value is at the discretion of the authorization server, but it MUST contain some part generated using a cryptographically strong pseudorandom algorithm such that it is computationally infeasible to predict or guess a valid value (see Section 10.10 of [RFC6749] for specifics). The authorization server MAY construct the "request_uri" value using the form "urn:ietf:params:oauth:request_uri:<reference-value>" with "<reference-value>" as the random part of the URI that references the respective authorization request data.

"request_uri" の値の形式は認可サーバーの裁量であるが、有効な値を予測または推測することが計算上実行不可能となるよう、暗号学的に強い擬似乱数アルゴリズムを使って生成された部分を含まなければならない (MUST) (詳細は [RFC6749] の 10.10 節を参照)。認可サーバーは、該当する認可リクエストデータを参照する URI のランダム部分を "<reference-value>" として、"urn:ietf:params:oauth:request_uri:<reference-value>" の形式で "request_uri" の値を構成してよい (MAY)。

The "request_uri" value MUST be bound to the client that posted the authorization request.

"request_uri" の値は、認可リクエストを投稿したクライアントに束縛されなければならない (MUST)。

The following is an example of such a response:

以下はそのような応答の例である:

2.3.Error Response

2.3.エラー応答

The authorization server returns an error response with the same format as is specified for error responses from the token endpoint in Section 5.2 of [RFC6749] using the appropriate error code from therein or from Section 4.1.2.1 of [RFC6749]. In those cases where Section 4.1.2.1 of [RFC6749] prohibits automatic redirection with an error back to the requesting client and hence doesn't define an error code (for example, when the request fails due to a missing, invalid, or mismatching redirection URI), the "invalid_request" error code can be used as the default error code. Error codes defined by the OAuth extension can also be used when such an extension is involved in the initial processing of the authorization request that was pushed. Since initial processing of the pushed authorization request does not involve resource owner interaction, error codes related to user interaction, such as "consent_required" defined by [OIDC], are never returned.

認可サーバーは、[RFC6749] の 5.2 節でトークンエンドポイントからのエラー応答向けに規定されたものと同じ形式で、同節または [RFC6749] の 4.1.2.1 節の適切なエラーコードを使ってエラー応答を返す。[RFC6749] の 4.1.2.1 節が要求元クライアントへのエラーを伴う自動リダイレクトを禁止しており、そのためエラーコードを定義していない場合 (例えば、リダイレクト URI の欠落、無効、または不一致によりリクエストが失敗した場合) には、"invalid_request" エラーコードをデフォルトのエラーコードとして使うことができる。プッシュされた認可リクエストの初期処理に OAuth 拡張が関与する場合、その拡張で定義されたエラーコードも使うことができる。pushed authorization request の初期処理にはリソースオーナーとのやり取りが含まれないため、[OIDC] で定義される "consent_required" のようなユーザーとのやり取りに関するエラーコードが返されることは決してない。

If the client is required to use signed Request Objects, by either the authorization server or the client policy (see [RFC9101], Section 10.5), the authorization server MUST only accept requests complying with the definition given in Section 3 and MUST refuse any other request with HTTP status code 400 and error code "invalid_request".

認可サーバーまたはクライアントのポリシーのいずれかにより、クライアントが署名付き Request Object を使うことを要求されている場合 ([RFC9101] の 10.5 節を参照)、認可サーバーは 3 節で与えられる定義に準拠するリクエストのみを受け付けなければならず (MUST)、それ以外のあらゆるリクエストを HTTP ステータスコード 400 とエラーコード "invalid_request" で拒否しなければならない (MUST)。

In addition to the above, the PAR endpoint can also make use of the following HTTP status codes:

上記に加えて、PAR エンドポイントは次の HTTP ステータスコードも利用できる:

The following is an example of an error response from the PAR endpoint:

以下は PAR エンドポイントからのエラー応答の例である:

2.4.Management of Client Redirect URIs

2.4.クライアントのリダイレクト URI の管理

OAuth 2.0 [RFC6749] allows clients to use unregistered "redirect_uri" values in certain circumstances or for the authorization server to apply its own matching semantics to the "redirect_uri" value presented by the client at the authorization endpoint. However, the OAuth security BCP [OAUTH-SECURITY-TOPICS] as well as the OAuth 2.1 specification [OAUTH-V2] require an authorization server to exactly match the "redirect_uri" parameter against the set of redirect URIs previously established for a particular client. This is a means for early detection of client impersonation attempts and prevents token leakage and open redirection. As a downside, this can make client management more cumbersome since the redirect URI is typically the most volatile part of a client policy.

OAuth 2.0 [RFC6749] は、特定の状況においてクライアントが未登録の "redirect_uri" の値を使うことや、認可エンドポイントでクライアントが提示した "redirect_uri" の値に認可サーバーが独自の一致判定の意味論を適用することを許している。しかし、OAuth セキュリティ BCP [OAUTH-SECURITY-TOPICS] および OAuth 2.1 仕様 [OAUTH-V2] は、認可サーバーが "redirect_uri" パラメーターを、特定のクライアントについて事前に確立されたリダイレクト URI の集合と完全一致で照合することを要求している。これはクライアントのなりすまし試行を早期に検知する手段であり、トークンの漏洩とオープンリダイレクトを防ぐ。欠点として、リダイレクト URI は通常クライアントポリシーの中で最も変動しやすい部分であるため、クライアント管理がより煩雑になりうる。

The exact matching requirement MAY be relaxed when using PAR for clients that have established authentication credentials with the authorization server. This is possible since, in contrast to a conventional authorization request, the authorization server authenticates the client before the authorization process starts and thus ensures it is interacting with the legitimate client. The authorization server MAY allow such clients to specify "redirect_uri" values that were not previously registered with the authorization server. This will give the client more flexibility (e.g., to mint distinct "redirect_uri" values per authorization server at runtime) and can simplify client management. It is at the discretion of the authorization server to apply restrictions on supplied "redirect_uri" values, e.g., the authorization server MAY require a certain URI prefix or allow only a query parameter to vary at runtime.

認可サーバーとの間で認証クレデンシャルを確立しているクライアントについて PAR を使う場合、完全一致の要件は緩和してよい (MAY)。これが可能なのは、従来の認可リクエストとは対照的に、認可サーバーが認可プロセスの開始前にクライアントを認証し、それにより正当なクライアントとやり取りしていることを保証するからである。認可サーバーは、そのようなクライアントが認可サーバーに事前登録されていない "redirect_uri" の値を指定することを許可してよい (MAY)。これによりクライアントはより高い柔軟性を得る (例えば、認可サーバーごとに異なる "redirect_uri" の値を実行時に生成する) ことができ、クライアント管理を簡素化できる。提供された "redirect_uri" の値に制限を適用するかどうかは認可サーバーの裁量であり、例えば認可サーバーは特定の URI プレフィックスを要求したり、実行時に変化してよいのをクエリパラメーターのみに限定したりしてよい (MAY)。

3.The "request" Request Parameter

3."request" リクエストパラメーター

Clients MAY use the "request" parameter as defined in JAR [RFC9101] to push a Request Object JWT to the authorization server. The rules for processing, signing, and encryption of the Request Object as defined in JAR [RFC9101] apply. Request parameters required by a given client authentication method are included in the "application/ x-www-form-urlencoded" request directly and are the only parameters other than "request" in the form body (e.g., mutual TLS client authentication [RFC8705] uses the "client_id" HTTP request parameter, while JWT assertion-based client authentication [RFC7523] uses "client_assertion" and "client_assertion_type"). All other request parameters, i.e., those pertaining to the authorization request itself, MUST appear as claims of the JWT representing the authorization request.

クライアントは、JAR [RFC9101] で定義される "request" パラメーターを使って、Request Object JWT を認可サーバーにプッシュしてよい (MAY)。JAR [RFC9101] で定義される Request Object の処理、署名、および暗号化の規則が適用される。当該クライアント認証方式が要求するリクエストパラメーターは "application/x-www-form-urlencoded" リクエストに直接含められ、フォームボディ中で "request" 以外に存在する唯一のパラメーターである (例えば、相互 TLS クライアント認証 [RFC8705] は "client_id" HTTP リクエストパラメーターを使い、JWT アサーションに基づくクライアント認証 [RFC7523] は "client_assertion" と "client_assertion_type" を使う)。その他すべてのリクエストパラメーター、すなわち認可リクエスト自体に関係するものは、認可リクエストを表す JWT のクレームとして現れなければならない (MUST)。

The following is an example of a pushed authorization request using a signed Request Object with the same authorization request payload as the example in Section 2.1. The client is authenticated with JWT client assertion-based authentication [RFC7523] (extra line breaks and spaces for display purposes only):

以下は、2.1 節の例と同じ認可リクエストのペイロードを持つ署名付き Request Object を使った pushed authorization request の例である。クライアントは JWT クライアントアサーションに基づく認証 [RFC7523] で認証されている (余分な改行とスペースは表示目的のみ):

The authorization server MUST take the following steps beyond the processing rules defined in Section 2.1:

認可サーバーは、2.1 節で定義された処理規則に加えて、次のステップを実行しなければならない (MUST):

1. If applicable, decrypt the Request Object as specified in JAR [RFC9101], Section 6.1.

1. 該当する場合、JAR [RFC9101] の 6.1 節で規定されているとおりに Request Object を復号する。

2. Validate the Request Object signature as specified in JAR [RFC9101], Section 6.2.

2. JAR [RFC9101] の 6.2 節で規定されているとおりに Request Object の署名を検証する。

3. If the client has authentication credentials established with the authorization server, reject the request if the authenticated "client_id" does not match the "client_id" claim in the Request Object. Additionally, requiring the "iss" claim to match the "client_id" is at the discretion of the authorization server.

3. クライアントが認可サーバーとの間で認証クレデンシャルを確立している場合、認証された "client_id" が Request Object 内の "client_id" クレームと一致しなければリクエストを拒否する。加えて、"iss" クレームが "client_id" と一致することを要求するかどうかは認可サーバーの裁量である。

The following RSA key pair, represented in JSON Web Key (JWK) format [RFC7517], can be used to validate or recreate the Request Object signature in the above example (extra line breaks and indentation within values for display purposes only):

JSON Web Key (JWK) 形式 [RFC7517] で表現された次の RSA 鍵ペアは、上の例の Request Object の署名を検証または再作成するために使うことができる (値の中の余分な改行とインデントは表示目的のみ):

4.Authorization Request

4.認可リクエスト

The client uses the "request_uri" value returned by the authorization server to build an authorization request as defined in [RFC9101]. This is shown in the following example where the client directs the user agent to make the following HTTP request (extra line breaks and indentation for display purposes only):

クライアントは、認可サーバーから返された "request_uri" の値を使って、[RFC9101] で定義されるとおりに認可リクエストを構築する。これを次の例に示す。ここでクライアントはユーザーエージェントに次の HTTP リクエストを行わせる (余分な改行とインデントは表示目的のみ):

Since parts of the authorization request content, e.g., the "code_challenge" parameter value, are unique to a particular authorization request, the client MUST only use a "request_uri" value once. Authorization servers SHOULD treat "request_uri" values as one-time use but MAY allow for duplicate requests due to a user reloading/refreshing their user agent. An expired "request_uri" MUST be rejected as invalid.

認可リクエストの内容の一部、例えば "code_challenge" パラメーターの値は特定の認可リクエストに固有のものであるため、クライアントは "request_uri" の値を一度だけ使わなければならない (MUST)。認可サーバーは "request_uri" の値を一回限りの使用として扱うべきである (SHOULD) が、ユーザーがユーザーエージェントをリロード/リフレッシュすることによる重複したリクエストを許可してよい (MAY)。期限切れの "request_uri" は無効として拒否しなければならない (MUST)。

The authorization server MUST validate authorization requests arising from a pushed request as it would any other authorization request. The authorization server MAY omit validation steps that it performed when the request was pushed, provided that it can validate that the request was a pushed request and that the request or the authorization server's policy has not been modified in a way that would affect the outcome of the omitted steps.

認可サーバーは、プッシュされたリクエストから生じる認可リクエストを、他のあらゆる認可リクエストに対して行うのと同様に検証しなければならない (MUST)。認可サーバーは、そのリクエストがプッシュされたリクエストであったこと、およびリクエストまたは認可サーバーのポリシーが、省略するステップの結果に影響する形で変更されていないことを検証できるのであれば、リクエストがプッシュされた時点で実行した検証ステップを省略してよい (MAY)。

Authorization server policy MAY dictate, either globally or on a per- client basis, that PAR be the only means for a client to pass authorization request data. In this case, the authorization server will refuse, using the "invalid_request" error code, to process any request to the authorization endpoint that does not have a "request_uri" parameter with a value obtained from the PAR endpoint.

認可サーバーのポリシーは、全体として、またはクライアントごとに、クライアントが認可リクエストデータを渡す唯一の手段を PAR とすることを規定してよい (MAY)。この場合、認可サーバーは、PAR エンドポイントから取得した値を持つ "request_uri" パラメーターを含まない認可エンドポイントへのあらゆるリクエストの処理を、"invalid_request" エラーコードを使って拒否する。

5.Authorization Server Metadata

5.認可サーバーメタデータ

The following authorization server metadata parameters [RFC8414] are introduced to signal the server's capability and policy with respect to PAR.

PAR に関するサーバーの能力とポリシーを通知するため、次の認可サーバーメタデータパラメーター [RFC8414] を導入する。

pushed_authorization_request_endpoint The URL of the pushed authorization request endpoint at which a client can post an authorization request to exchange for a "request_uri" value usable at the authorization server.

pushed_authorization_request_endpoint クライアントが認可リクエストを投稿して、認可サーバーで使用可能な "request_uri" の値と引き換えることができる、pushed authorization request エンドポイントの URL。

require_pushed_authorization_requests Boolean parameter indicating whether the authorization server accepts authorization request data only via PAR. If omitted, the default value is "false".

require_pushed_authorization_requests 認可サーバーが認可リクエストデータを PAR 経由でのみ受け付けるかどうかを示すブール値パラメーター。省略された場合、デフォルト値は "false" である。

Note that the presence of "pushed_authorization_request_endpoint" is sufficient for a client to determine that it may use the PAR flow. A "request_uri" value obtained from the PAR endpoint is usable at the authorization endpoint regardless of other authorization server metadata such as "request_uri_parameter_supported" or "require_request_uri_registration" [OIDC.Disco].

クライアントが PAR フローを使ってよいと判断するには、"pushed_authorization_request_endpoint" の存在だけで十分であることに注意されたい。PAR エンドポイントから取得した "request_uri" の値は、"request_uri_parameter_supported" や "require_request_uri_registration" [OIDC.Disco] といった他の認可サーバーメタデータにかかわらず、認可エンドポイントで使用可能である。

6.Client Metadata

6.クライアントメタデータ

The Dynamic Client Registration Protocol [RFC7591] defines an API for dynamically registering OAuth 2.0 client metadata with authorization servers. The metadata defined by [RFC7591], and registered extensions to it, also imply a general data model for clients that is useful for authorization server implementations even when the Dynamic Client Registration Protocol isn't in play. Such implementations will typically have some sort of user interface available for managing client configuration. The following client metadata parameter is introduced by this document to indicate whether pushed authorization requests are required for the given client.

Dynamic Client Registration Protocol [RFC7591] は、OAuth 2.0 クライアントメタデータを認可サーバーに動的に登録するための API を定義している。[RFC7591] で定義されたメタデータとそれに対する登録済みの拡張は、Dynamic Client Registration Protocol が使われていない場合でも、認可サーバーの実装にとって有用なクライアントの一般的なデータモデルをも示唆している。そのような実装は通常、クライアント設定を管理するための何らかのユーザーインターフェースを備えている。当該クライアントに pushed authorization request が要求されるかどうかを示すため、本文書は次のクライアントメタデータパラメーターを導入する。

require_pushed_authorization_requests Boolean parameter indicating whether the only means of initiating an authorization request the client is allowed to use is PAR. If omitted, the default value is "false".

require_pushed_authorization_requests クライアントが認可リクエストを開始するために使うことを許される唯一の手段が PAR であるかどうかを示すブール値パラメーター。省略された場合、デフォルト値は "false" である。

7.Security Considerations

7.セキュリティに関する考慮事項

7.1.Request URI Guessing

7.1.リクエスト URI の推測

An attacker could attempt to guess and replay a valid request URI value and try to impersonate the respective client. The authorization server MUST account for the considerations given in JAR [RFC9101], Section 10.2, clause (d) on request URI entropy.

攻撃者は有効なリクエスト URI の値を推測して再生し、該当するクライアントになりすまそうとする可能性がある。認可サーバーは、JAR [RFC9101] の 10.2 節の (d) 項に示されたリクエスト URI のエントロピーに関する考慮事項を踏まえなければならない (MUST)。

7.2.Open Redirection

7.2.オープンリダイレクト

An attacker could try to register a redirect URI pointing to a site under their control in order to obtain authorization codes or launch other attacks towards the user. The authorization server MUST only accept new redirect URIs in the pushed authorization request from authenticated clients.

攻撃者は、認可コードを取得したりユーザーに対する他の攻撃を仕掛けたりするために、自身の制御下にあるサイトを指すリダイレクト URI を登録しようとする可能性がある。認可サーバーは、pushed authorization request における新しいリダイレクト URI を、認証されたクライアントからのみ受け入れなければならない (MUST)。

7.3.Request Object Replay

7.3.Request Object の再生

An attacker could replay a request URI captured from a legitimate authorization request. In order to cope with such attacks, the authorization server SHOULD make the request URIs one-time use.

攻撃者は、正当な認可リクエストから取得したリクエスト URI を再生する可能性がある。そのような攻撃に対処するため、認可サーバーはリクエスト URI を一回限りの使用にすべきである (SHOULD)。

7.4.Client Policy Change

7.4.クライアントポリシーの変更

The client policy might change between the lodging of the Request Object and the authorization request using a particular Request Object. Therefore, it is recommended that the authorization server check the request parameter against the client policy when processing the authorization request.

クライアントポリシーは、Request Object の登録と、その特定の Request Object を使った認可リクエストとの間で変更される可能性がある。したがって、認可サーバーは認可リクエストを処理する際に、リクエストパラメーターをクライアントポリシーに照らして確認することが推奨される。

7.5.Request URI Swapping

7.5.リクエスト URI のすり替え

An attacker could capture the request URI from one request and then substitute it into a different authorization request. For example, in the context of OpenID Connect, an attacker could replace a request URI asking for a high level of authentication assurance with one that requires a lower level of assurance. Clients SHOULD make use of PKCE [RFC7636], a unique "state" parameter [RFC6749], or the OIDC "nonce" parameter [OIDC] in the pushed Request Object to prevent this attack.

攻撃者は、あるリクエストからリクエスト URI を取得し、それを別の認可リクエストに差し替える可能性がある。例えば OpenID Connect の文脈では、攻撃者は高い認証保証レベルを求めるリクエスト URI を、より低い保証レベルを要求するものに置き換えることができる。クライアントはこの攻撃を防ぐため、プッシュする Request Object において PKCE [RFC7636]、一意な "state" パラメーター [RFC6749]、または OIDC の "nonce" パラメーター [OIDC] を利用すべきである (SHOULD)。

8.Privacy Considerations

8.プライバシーに関する考慮事項

OAuth 2.0 is a complex and flexible framework with broad-ranging privacy implications due to its very nature of having one entity intermediate user authorization to data access between two other entities. The privacy considerations of all of OAuth are beyond the scope of this document, which only defines an alternative way of initiating one message sequence in the larger framework. However, using PAR may improve privacy by reducing the potential for inadvertent information disclosure since it passes the authorization request data directly between the client and authorization server over a secure connection in the message body of an HTTP request rather than in the query component of a URL that passes through the user agent in the clear.

OAuth 2.0 は複雑で柔軟なフレームワークであり、ある主体が他の二つの主体の間でデータアクセスに対するユーザーの認可を仲介するというその本質ゆえに、広範なプライバシー上の含意を持つ。OAuth 全体のプライバシーに関する考慮事項は本文書の範囲を超えており、本文書はより大きなフレームワークの中の一つのメッセージシーケンスを開始する代替の方法を定義するに過ぎない。しかし、PAR の使用は、認可リクエストデータを、ユーザーエージェントを平文で通過する URL のクエリ部分ではなく、安全な接続上の HTTP リクエストのメッセージボディでクライアントと認可サーバーの間で直接受け渡すため、意図しない情報開示の可能性を減らし、プライバシーを向上させうる。

9.IANA Considerations

9.IANA に関する考慮事項

9.1.OAuth Authorization Server Metadata

9.1.OAuth 認可サーバーメタデータ

IANA has registered the following values in the IANA "OAuth Authorization Server Metadata" registry of [IANA.OAuth.Parameters] established by [RFC8414].

IANA は、[RFC8414] によって確立された [IANA.OAuth.Parameters] の IANA "OAuth Authorization Server Metadata" レジストリに次の値を登録した。

Metadata Name: "pushed_authorization_request_endpoint" Metadata Description: URL of the authorization server's pushed authorization request endpoint. Change Controller: IESG Specification Document(s): Section 5 of RFC 9126

Metadata Name: "pushed_authorization_request_endpoint" Metadata Description: 認可サーバーの pushed authorization request エンドポイントの URL。 Change Controller: IESG Specification Document(s): RFC 9126 の 5 節

Metadata Name: "require_pushed_authorization_requests" Metadata Description: Indicates whether the authorization server accepts authorization requests only via PAR. Change Controller: IESG Specification Document(s): Section 5 of RFC 9126

Metadata Name: "require_pushed_authorization_requests" Metadata Description: 認可サーバーが認可リクエストを PAR 経由でのみ受け付けるかどうかを示す。 Change Controller: IESG Specification Document(s): RFC 9126 の 5 節

9.2.OAuth Dynamic Client Registration Metadata

9.2.OAuth 動的クライアント登録メタデータ

IANA has registered the following value in the IANA "OAuth Dynamic Client Registration Metadata" registry of [IANA.OAuth.Parameters] established by [RFC7591].

IANA は、[RFC7591] によって確立された [IANA.OAuth.Parameters] の IANA "OAuth Dynamic Client Registration Metadata" レジストリに次の値を登録した。

Client Metadata Name: "require_pushed_authorization_requests" Client Metadata Description: Indicates whether the client is required to use PAR to initiate authorization requests. Change Controller: IESG Specification Document(s): Section 6 of RFC 9126

Client Metadata Name: "require_pushed_authorization_requests" Client Metadata Description: クライアントが認可リクエストを開始するために PAR の使用を要求されるかどうかを示す。 Change Controller: IESG Specification Document(s): RFC 9126 の 6 節

9.3.OAuth URI Registration

9.3.OAuth URI の登録

IANA has registered the following value in the "OAuth URI" registry of [IANA.OAuth.Parameters] established by [RFC6755].

IANA は、[RFC6755] によって確立された [IANA.OAuth.Parameters] の "OAuth URI" レジストリに次の値を登録した。

URN: "urn:ietf:params:oauth:request_uri:" Common Name: A URN Sub-Namespace for OAuth Request URIs. Change Controller: IESG Specification Document(s): Section 2.2 of RFC 9126

URN: "urn:ietf:params:oauth:request_uri:" Common Name: OAuth リクエスト URI のための URN サブ名前空間。 Change Controller: IESG Specification Document(s): RFC 9126 の 2.2 節

10.References

10.参考資料

10.1.Normative References

10.1.引用規格

10.2.Informative References

10.2.参考文献

Acknowledgements

謝辞

This specification is based on the work on Pushed Request Object (https://bitbucket.org/openid/fapi/src/master/ Financial_API_Pushed_Request_Object.md) conducted at the Financial- grade API Working Group at the OpenID Foundation. We would like to thank the members of the WG for their valuable contributions.

本仕様は、OpenID Foundation の Financial-grade API ワーキンググループで行われた Pushed Request Object (https://bitbucket.org/openid/fapi/src/master/ Financial_API_Pushed_Request_Object.md) に関する作業に基づいている。WG のメンバーの貴重な貢献に感謝する。

We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle Backman, Joseph Heenan, Sean Glencross, Maggie Hung, Neil Madden, Karsten Meyer zu Selhausen, Roman Danyliw, Meral Shirazipour, and Takahiko Kawasaki for their valuable feedback on this document.

本文書への貴重なフィードバックをくれた Vladimir Dzhuvinov、Aaron Parecki、Justin Richer、Sascha Preibisch、Daniel Fett、Michael B. Jones、Annabelle Backman、Joseph Heenan、Sean Glencross、Maggie Hung、Neil Madden、Karsten Meyer zu Selhausen、Roman Danyliw、Meral Shirazipour、および Takahiko Kawasaki に感謝する。