Applications can use a pushed authorization request (PAR) to securely initiate authorization flows. A PAR allows applications to send their authorization requests directly to PingOne, without going through the browser, which safeguards sensitive data from end-user devices.
With a PAR, an application can push an authorization request payload to PingOne with a direct back-channel request, which is a more secure method of sending sensitive data, such as personally identifiable information, than sending it with a browser on the front channel.
The authorization request payload contains parameters that are application/x-www-form-urlencoded formatted. PingOne can accept all parameters that usually make up an authorization request and any additional parameters needed for client authentication. It also can accept signed requests.
- PingOne will not accept PAR requests that are larger than 1 MB.
- PingOne accepts requests through HTTP POST only.
After PingOne validates the request and saves the payload, it returns the request_uri parameter as a reference to the payload. The response also indicates the lifetime of the request URI. The default lifetime is 60 seconds.
The application then uses the front channel to request an authorization code or token, sending the request_uri parameter to PingOne. PingOne uses the request URI to look up the request payload and continue the authorization flow. PingOne accepts a particular request URI only once.
For more information about the PAR protocol, see OAuth 2.0 Pushed Authorization Requests on the IETF website.
PAR and application types
PAR secures authorization requests, so PAR applies to the Authorization Code grant type and the Implicit grant type. In PingOne, each application type has its own default grant type. The following table shows PAR availability by application type.
|
App type |
Grant type configured when the application was created |
Can the app send a PAR to PingOne? |
|---|---|---|
|
OIDC Web App |
Authorization Code |
Yes |
|
Native |
Authorization Code Implicit |
Yes |
|
Single-page |
Implicit |
Yes |
|
Worker |
Client credentials |
No. A non-interactive Worker app using the Client credentials grant type sends token requests to the token endpoint only. A non-interactive Worker app does not send authorization requests. However, you can configure a Worker app to use a user-based grant type, such as Authorization Code or Implicit. An interactive app can therefore send authorization requests and PARs to PingOne. |