Using Pushed Authorization Requests

"Pushed Authorization Requests" (PAR) is a 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.

Prerequisites

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 https://idsvr.example.com/oauth/v2/oauth-authorize, then the PAR endpoint has the URL https://idsvr.example.com/oauth/v2/oauth-authorize/par. 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).

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.

Testing the Flow

You can use OAuth Tools to perform an authorization flow using PAR. Open a new Code Flow and toggle the Pushed Authorization Request (PAR) option. If you don't see that toggle just above OpenID Settings, then go to Environments and refresh metadata for your instance of the Curity Identity Server. Make sure that the "Pushed Authorization Request Endpoint" value is set.

Once PAR is enabled, then the client authorization method can be chosen. This depends on the methods available to the given client.

The flow will now have an additional step. Click the Send button to send a request to the PAR endpoint and obtain a request_uri. In the next step the authorization flow will be started using the request_uri obtained from the PAR endpoint.

Conclusion

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