Using Pushed Authorization Requests

Using Pushed Authorization Requests


“Pushed Authorization Requests” (PAR) is a draft specification which standardizes the way in which the Authorization Server can be used to provide request objects URIs, which the client can then utilize in an authorization request. This essentially standardizes by-reference request objects. You can read more about PAR itself in the Pushed Authorization Requests article.

This tutorial shows how to configure the Curity Identity Server so that clients can call a PAR endpoint in order to obtain a reference to a request object.


Make sure that you’re running the Curity Identity Server in version 6.3.0 or later. If running a clean instance of the Curity Identity Server, make sure to configure it at least with the basic configuration.

Configuring PAR

A PAR endpoint is exposed by the Curity Identity Server by default, no additional configuration is needed to enable it. The endpoint has the path /par appended to the authorize endpoint path. E.g. if the authorize endpoint URL is, then the PAR endpoint has the URL Any client which can call the authorize endpoint, can also call the PAR endpoint. This will usually mean a client which has the code or the implicit flow enabled.

Using PAR can be required by the Curity Identity Server, either at profile or client level. To require it at profile level, in the admin UI, enable the Require Pushed Authorization Requests option in System -> Profiles -> Token Service -> Client Settings -> Code Flow. To require it for a given client, enable the Require Pushed Authorization Requests option in the Client Application Settings -> Advanced tab, when editing a client. When PAR is required, then a client (or all clients) can initiate authorization only by sending a request object reference previously obtained from the PAR endpoint.

Client Authentication at the PAR Endpoint

The specification states that the PAR endpoint should authenticate the client with the same method that it uses for the token endpoint. This means that, in the Curity Identity Server, the client authentication which will be used at the PAR endpoint, depends on the client Authentication Method settings. For example, if the client uses secret as the Authentication Method, then a Basic Authorization Header should be sent together with the PAR request. If the client authenticates with asymmetrically signed JWT, then it should add client_assertion_type and client_assertion parameters to the request with a valid signed JWT.

It is technically possible to allow unauthenticated access to the PAR endpoint if you select no-authentication as the client Authentication Method. This however beats the purpose of using PAR. The reason behind using PAR is to be able to hide request parameter values, as they are exchanged directly between the client and the Authorization Server, not through a browser. It also gives security benefits, as the server can validate the parameters before they are used in an authorization request. If the PAR endpoint can be accessed without authorization, then the server does not have proper means of validating the authenticity of the request parameters. In this situation, the client is a public client, probably run in the browser, which means that there is still potential to eavesdrop the communication between that client and the Authorization Server. Thus, even though it is technically possible, it is not recommended to use PAR without authorization.

Allowing Per-Request Redirect URIs

Because the client calling the PAR endpoint is authenticated, the Curity Identity Server can relax requirements for redirect URI. If you allow per-request redirect URIs, then the PAR request can contain a redirect URI which shares only the same origin as a redirect URI registered for the client. This allows using dynamically generated redirect URIs. To allow this option, first enable it on the profile level. In the admin UI, go to the System -> Profiles -> Token Service -> Client Settings -> Code Flow tab and enable Allow Per Request Redirect URIs. Once this is enabled, then you can allow per-request redirect URIs for a concrete client, by enabling the same option in the Client Application Settings -> Advanced tab, when editing a client (Require Pushed Authorization Requests on the client has to be enabled).

Enabled per-request redirect URIs

Combining PAR and JAR

It is possible to combine the two specifications: Pushed Authorization Requests and JWT Authorization Requests. If you enable JAR for a client, then it can send a request to the PAR endpoint using the signed or encrypted JWT, instead of the parameters sent as form fields in the request’s body. The JAR Tutorial shows how to configure JAR in the Curity Identity Server.

Using the PAR Endpoint to Initialize an Authentication

To initiate an authorization flow using PAR, first make a request to the PAR endpoint:

curl --basic -u client_id:Secr3t -d "client_id=client_id&response_type=code&redirect_uri=http://localhost"

This example assumes that the client authenticates with the secret method, and has client ID client_id and secret Secr3t. The request contains the minimal set of parameters required to create a request object: client_id (which should match the one from authentication), response_type and redirect_uri.

The Authorization Server will send a response containing the URN of the request object:


This can now be used to perform an authorization request. In the browser navigate to the following URL. This will start the familiar OAuth code flow.


“Pushed Authorization Requests” is a built-in feature of the Curity Identity Server which doesn’t need any complicated configuration. Any confidential client can easily start using PAR, to further protect privacy and integrity of authorization requests.

Let’s Stay in Touch!

Get the latest on identity management, API Security and authentication straight to your inbox.

Keep up with our latest articles and how-tos using RSS feeds