Skip to main content

OAuth Pushed Authorization Requests (PAR)

Learn what pushed authorization requests (PARs) are, what their advantages are, and when you should think about enabling PAR. Get familiar with the endpoint for pushed authorization requests. Learn how SecureAuth provides you with a possibility to use PAR.

What Pushed Authorization Requests (PAR) Are

OAuth 2.0 Pushed Authorization Requests (PAR) is an OAuth 2.0 specification for the PAR endpoint that allows client applications to push the payloads of authorization requests to authorization server (in this case, SecureAuth) via direct requests to the PAR endpoint. In return, the client application receives a request URI that is used as a reference to the previously sent payload data in a subsequent call to the authorization server (SecureAuth).

Pushed_Authorization_Requests__PAR_.svg

When to Use PAR

PAR should be used by client applications that require the highest level of security. It is one of the prerequisites to be compliant with some of the profiles for FAPI security profile, as well as some of the profiles for Consumer Data Right (CDR) Australian Open Banking directive. Even if you are not pursuing FAPI or CDR certification, you should consider enabling PAR for your client applications to further enhance their security level.

How PAR Works

With OAuth 2.0 or OpenID Connect, authorization request parameters are usually provided to authorization servers using URI query parameters via redirection in the user agent (typically, a browser), which presents some risks:

  • There is no cryptographical integrity or authenticity protection involved and the access scope requested can be modified.

  • Confidentiality of the request parameters cannot be ensured even when HTTPS protocol is used as the data passes through the user agent and can be leaked to the webserver logs or other sites via referrer.

  • Authorization request URL can become too long for the user agent to be processed successfully.

The biggest benefit of Pushed Authorization Requests is solving the problems listed above. It improves the security of your requests by providing client applications with a secure mean for a confidential and integrity-protected authorization requests.

Authorization Code Flow With PAR

  1. Client application sends a request to the SecureAuth's /par endpoint.

    The request:

    • must contain the same parameters as it does when a request is sent to the SecureAuth's OAuth 2.0 authorize endpoint.

    • The request must also contain the parameters used for client authentication method set for this client.

  2. When the request reaches SecureAuth:

    1. SecureAuth authenticates the client in the same way as the client would be authenticated when making a call to the SecureAuth's OAuth 2.0 token endpoint

      To learn more, see Client Authentication.

    2. SecureAuth rejects the request if it contains the request_uri parameter.

      The request_uri parameter is used for getting client applications authorized. SecureAuth rejects requests to the PAR endpoint that contain the request_uri as allowing it would cause a conflict between the request_uri provided in the request and the request_uri received as a response parameter after making a successful call to the /par endpoint.

    3. SecureAuth validates the request as it would validate a request to the OAuth 2.0 authorize endpoint.

      For example, SecureAuth validates if the redirection URI matches the redirection URIs configured for the client application that is making a request to the /par endpoint. Among other checks, SecureAuth also validates if the client application is authorized to request the scope provided in the request.

      Policies Enforcement

      Even though SecureAuth performs validation of the request, the policies are not enforced for the /par endpoint. It means that, for example, if you have a policy for APIs that checks if your request contains a particular scope or header, this policy does not apply for the /par endpoint and its result is only evaluated when a call to the OAuth 2.0 authorize endpoint is made.

  3. After a successful verification of the request, SecureAuth responds with the 201 HTTP status code and provides two response parameters:

    • Single-use request_uri that is corresponding to the authorization request to be posted.

    • expires_in which is a JSON number that represents the lifetime of your request URI. If the request URI expires, any request to the OAuth 2.0 authorize endpoint made using this URI is declined.

      PAR lifetime

      You can adjust your expiration time for your request URIs in your workspace authorization settings.

  4. The client application can now make a request to the OAuth 2.0 authorize endpoint using the request URI that it received as the response when calling the /par endpoint.

In this section: