Pushed Authorization Requests (PAR)

The OAuth 2.0 Pushed Authorization Requests is a specification that standardizes a secure way of initiating an OAuth or OIDC authorization flow. It is also being incorporated into other standards, like the Financial-grade APIs Part 2 specification. As PAR is relatively stable and adopted, it can safely be assumed that it will soon become an RFC standard.

What Are Pushed Authorization Requests (PAR)?

Both OAuth and OpenID Connect introduced an ability to initialize a flow by using a request object instead of sending the parameters in a query string. Using request objects in an authorization request resolves a few issues. For complex authorization queries, the URL can become too large to be properly handled by some browsers. It can also slow down the request on slower connections (especially mobile networks). Additionally, the Authorization Server has no means of checking whether the request has been tampered with in a usual authorization request. Using a request object solves the former issue, and signing the request object solves the latter.

Specifications that describe request objects (OIDC Core and JWT Secured Authorization Requests (JAR)) give you two options for sending the request — either by sending the object in the request query parameter or by providing a request_uri which points to the object. The Pushed Authorization Requests specification standardizes how the Authorization Server is used to register the request object and provide the URI, which can subsequently be used in an authorization request. This means that using PAR solves the aforementioned problems, but also helps to enhance the security and privacy of the request even further.

How PAR Works

For the client to use PAR, the Authorization Server must expose a new endpoint where the client can send the authorization request parameters. The client's parameters typically sent in the query string are instead sent in the body of a POST request.

POST /authorize/par HTTP/1.1
 Host: idsvr.example.com
 Content-Type: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

 response_type=code
 &client_id=s6BhdRkqt3&state=af0ifjsldkj
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

Additionally, if the client is confidential (it can authenticate at the Authorization Server), it authenticates using the same method it uses at the token endpoint. For example, with Basic Authentication or by using a client certificate (Mutual TLS). The Authorization Server can verify the client and the parameters. For example, it checks whether the client can request the given scopes, whether the client sent state or code_challenge parameters (if it uses PKCE). Once the request is verified, the Authorization Server persists the parameters and issues a URN for the request object, which it sends in the response.

HTTP/1.1 201 Created
Content-Type: application/json

{
    "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
    "expires_in": 90
 }

The client then uses that URN in the authorization request made through a user-agent. The request_uri parameter is used to send the reference to the request object.

https://idsvr.example.com/authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2

The Authorization Server can use the parameters stored for that URN to perform an authorization flow. As these parameters were validated before, the Authorization Server knows that they could not have been tampered with and that the request is valid.

All the request parameters are exchanged directly between the client and the Authorization Server using a secure connection; no user-agent is needed. Thanks to this, the parameter values will not be revealed, for example, through the browser's logs. Although this level of privacy can be achieved by using encrypted request objects, using PAR does not require the client to use application-level cryptography; thus, it doesn't require any client key management.

Metadata Describing PAR

The PAR specification adds three new metadata entries which describe the level of support for this feature.

pushed_authorization_request_endpoint exposed in the server's metadata contains the URL of the PAR endpoint. If the server's metadata includes this entry, it means that the server supports Pushed Authorization Requests.

require_pushed_authorization_requests exposed in the server's metadata states whether clients are required to use PAR. If set to true, clients cannot initialize authorization requests by sending authorization parameters in query strings or requesting objects.

require_pushed_authorization_requests in the Dynamic Client Registration metadata informs the server whether the given registered client must use PAR to initialize authorization flows.

Security Improvements in PAR

When PAR is used, the client only sends the URI of the request object through the browser. This makes the authorization request lightweight and protects from tampering with the authorization request parameters. These improvements are also provided by using signed request objects, although using PAR gives some additional benefits.

All the authorization request parameters are sent directly from the client to the Authorization Server without ever being exposed to the user-agent. Even though a secure connection is always used — regardless of whether the request goes through the browser or not — TLS is terminated in the browser, so the user-agent has access to these parameters in plain text. This could accidentally be leaked when the browser writes query parameters to some logs. An attacker is also able to tamper with these parameters at this point. This vulnerability is mitigated when using PAR without implementing request object encryption on the client-side. This also enables clients to safely use Personally Identifiable Information (PII) in the authorization parameters. In this scenario, the client is sure that this information will not be exposed.

Another important security improvement of PAR is that confidential clients are authenticated when sending a request to the PAR endpoint. This means that the Authorization Server can authenticate the client before the authorization flow begins. In a standard OAuth flow, the client only authenticates when making a call to the token endpoint. This leaves the authorization endpoint vulnerable to attacks, where a malicious party could try to impersonate a client and inject malformed parameters. With PAR, the Authorization Server can reject malformed or unauthorized requests early on before they are used in an authorization flow. This feature also allows the Authorization Server to relax the requirements for a redirect URI. Because the client is authenticated, the Authorization Server can use redirect URIs that were not previously registered. For example, it may allow the client to easily use redirect URIs that include dynamic subdomains or paths.

Because of the security improvements described earlier, PAR is an excellent addition to Financial Grade APIs and is mentioned in the FAPI specification numerous times. Although not strictly required, it helps to make the authorization request much more secure and increases the Authorization Server's certainty of the authenticity of the request. PAR, together with Rich Authorization Requests, will make it possible for an Authorization Server to implement lodging intent, a scenario used in financial-grade APIs for getting a user's consent to a concrete transaction.

Conclusion

Pushed Authorization Requests (PAR) give you security and privacy improvements without having to implement costly cryptography at the client-side. The client needs only minimal changes to be able to use PAR instead of a standard authorization request. The feature will be especially useful in financial-grade scenarios, where increased security and privacy are required.