PingOne

Pushed authorization requests

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 doesn’t accept PAR requests 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.

Learn more about the PAR protocol in OAuth 2.0 Pushed Authorization Requests on the Internet Engineering Task Force (IETF) website.

PAR and application types

PAR secures authorization requests, so PAR applies to the authorization code and implicit grant types. In PingOne, each application type has its own default grant type. The following table shows PAR availability by application type:

Application type Grant type configured when the application was created Can the application send a PAR to PingOne?

OIDC web application

Authorization code

Yes

Native

Authorization code Implicit

Yes

Single page

Implicit

Yes

Device authorization

Device authorization

Not applicable. An application using the device authorization grant type sends a device authorization request to the device authorization endpoint.

Worker

Client credentials

No. A non-interactive worker application using the client credentials grant type sends token requests to the token endpoint only. A non-interactive worker application doesn’t send authorization requests.

However, you can configure a worker application to use a user-based grant type, such as authorization code or implicit. An interactive application can send authorization requests and PARs to PingOne.