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, Cloudentity) 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 (Cloudentity).
Try it now
Cloudentity comes with multi-tenant authorization server as a service that supports Pushed Authorization Requests (PAR).
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
Client application sends a request to the Cloudentity’s
must contain the same parameters as it does when a request is sent to the Cloudentity’s OAuth 2.0 authorize endpoint.
The request must also contain the parameters used for client authentication method set for this client.
When the request reaches Cloudentity:
Cloudentity authenticates the client in the same way as the client would be authenticated when making a call to the Cloudentity’s OAuth 2.0 token endpoint
To learn more, see client authentication methods article.
Cloudentity rejects the request if it contains the
request_uriparameter is used for getting client applications authorized. Cloudentity rejects requests to the PAR endpoint that contain the
request_urias allowing it would cause a conflict between the
request_uriprovided in the request and the
request_urireceived as a response parameter after making a successful call to the
Cloudentity validates the request as it would validate a request to the OAuth 2.0 authorize endpoint.
For example, Cloudentity validates if the redirection URI matches the redirection URIs configured for the client application that is making a request to the
/parendpoint. Among other checks, Cloudentity also validates if the client application is authorized to request the scope provided in the request.
Even though Cloudentity performs validation of the request, the policies are not enforced for the
/parendpoint. 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
/parendpoint and its result is only evaluated when a call to the OAuth 2.0 authorize endpoint is made.
After a successful verification of the request, Cloudentity responds with the
201 HTTPstatus code and provides two response parameters:
request_urithat is corresponding to the authorization request to be posted.
expires_inwhich 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.
You can adjust your expiration time for your request URIs in your workspace authorization settings.
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