Orchestration SDKs

OAuth 2.0 security with Pushed Authorization Requests

Pushed Authorization Requests (PAR) is an OAuth 2.0 extension defined in RFC 9126 that improves the security of the OIDC redirect login flow.

PAR moves authorization parameters out of the browser redirect URL and into a direct, server-side request, reducing their exposure and protecting their integrity.

The problem PAR solves

In a standard OIDC redirect flow, authorization parameters such as client_id, redirect_uri, scope, state, and any acr_values are sent as query parameters in the browser’s address bar when redirecting to the authorization server.

This exposes those parameters in several places:

  • Browser history and URL bars

  • Proxy and network access logs

  • HTTP Referer headers sent to third-party resources on the authorization server’s page

In addition, browsers can impose URL length limits. Complex requests with many parameters, such as those encoding rich claims or long acr_values strings, can exceed those limits and cause errors.

How PAR works

With PAR, the client sends authorization parameters directly to the authorization server’s /par endpoint over a backchannel POST request before the browser redirect occurs.

The authorization server validates the parameters, stores them, and returns a short-lived request_uri that acts as an opaque reference.

The browser redirect to the /authorize endpoint then uses only that request_uri, keeping all sensitive parameters out of the URL.

ClientAuthorization ServerBrowserClientClientAuthorization ServerAuthorization ServerBrowserBrowser1POST /par(client_id, scope, redirect_uri,state, code_challenge)Parameters sent in request body —not visible in the URL.2201 Created(request_uri, expires_in)3Navigate to /authorize(client_id, request_uri)4GET /authorizeServer retrieves stored paramsusing request_uri.5302 Redirect to redirect_uri
Figure 1. PAR authorization flow

This approach provides the following security benefits:

Reduced parameter exposure

Authorization parameters are no longer visible in browser history, proxy logs, or referrer headers.

Integrity protection

Parameters are submitted directly to the authorization server before the browser redirect, so they cannot be tampered with in transit.

No URL length limits

Complex authorization requests are no longer constrained by browser URL length restrictions.

PAR and PKCE

PAR and PKCE are complementary security measures that work well together.

PKCE protects the authorization code exchange by binding a code_challenge to the initial authorization request and requiring the matching code_verifier when exchanging the code for tokens.

PAR carries the PKCE code_challenge as one of its parameters, so both protections apply to the same request.

Using PAR and PKCE together provides both confidentiality (parameters are not exposed in the URL) and integrity (the code exchange cannot be replayed or intercepted).

When the par option is enabled in the SDK configuration, the Orchestration SDKs use both PKCE and PAR together.

Enabling PAR in the SDK

PAR is opt-in.

Set the par option to true in your SDK configuration to enable it.

Once enabled, the SDK reads the pushed_authorization_request_endpoint URL automatically from the server’s .well-known/openid-configuration document, sends authorization parameters to that endpoint before the browser redirect, and uses the returned request_uri in the subsequent /authorize redirect.

PAR is supported for OIDC sign-on with PingOne, PingOne Advanced Identity Cloud, and PingAM.

Configuration instructions

For server configuration steps and platform-specific SDK usage, see Securing OIDC sign-on with Pushed Authorization Requests.