1. Introduction

1. Introduction

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.

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:

• 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).

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

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.

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.

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 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.

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.

See 1.1. Introductory Example and 1.2. Conventions and Terminology.