Insights on Crypto Payments, Infrastructure, and Operations

Pushed Authorization Request (PAR)

Abbreviation: PAR

Pronunciation: poosht aw-thor-ih-ZAY-shun ree-KWEST

Also known as: OAuth Pushed Authorization Request, PAR

Definition

Pushed Authorization Request (PAR) is an OAuth mechanism in which a client sends authorization-request parameters directly to the authorization server before redirecting the user with a short request URI. PAR protects delivery and validation of request parameters; JAR protects parameters cryptographically, and the two mechanisms can be combined.

Overview

Meaning and scope

Pushed Authorization Request (PAR) is an OAuth mechanism in which a client sends authorization-request parameters directly to the authorization server before redirecting the user with a short request URI. PAR protects delivery and validation of request parameters; JAR protects parameters cryptographically, and the two mechanisms can be combined.

Mechanism and operation

The Pushed Authorization Request (PAR) recovery process should restore access without bypassing the original identity and authorization controls. A production implementation should authenticate the client where required, validate the pushed request, issue short-lived single-purpose request URIs, bind them to the client, and prevent parameter substitution at the browser-facing endpoint. Useful measures include pushed-request success rate, invalid request URIs, replay attempts, expired requests, client-authentication failures, and authorization abandonment after PAR. Changes to Pushed Authorization Request (PAR) should preserve overlap or recovery where required while preventing old credentials from remaining active indefinitely. Evidence for Pushed Authorization Request (PAR) should record the credential or certificate identifier and decision result without retaining the secret itself.

Practical payment example

An OAuth client submits authorization parameters directly to the authorization server before redirecting the user. The server returns a request URI, limiting exposure and tampering of those parameters in the browser.

Operational checks

Monitoring for Pushed Authorization Request (PAR) should track failed use, unusual scope or audience, expiry, rotation status, and attempts involving revoked credentials. Least-privilege configuration for Pushed Authorization Request (PAR) should be verified against the operations used by each environment and consuming service. A compromise response for Pushed Authorization Request (PAR) should support rapid revocation, replacement, affected-client identification, and review of prior use.

Distinctions and limits

Key risks include request URI replay, weak client binding, excessive lifetime, accepting browser parameters that override pushed values, denial of service through stored requests, and inconsistent validation between endpoints.

Related definitions: Authorization Endpoint, JWT Secured Authorization Request (JAR).

Example

An OAuth client submits authorization parameters directly to the authorization server before redirecting the user. The server returns a request URI, limiting exposure and tampering of those parameters in the browser.

Comparison

Key risks include request URI replay, weak client binding, excessive lifetime, accepting browser parameters that override pushed values, denial of service through stored requests, and inconsistent validation between endpoints.

Key Takeaway

Authenticate the client where required, validate the pushed request, issue short-lived single-purpose request URIs, bind them to the client, and prevent parameter substitution at the browser-facing endpoint.

Sources

  1. OAuth 2.0 Pushed Authorization Requests — IETF (2026-08-03)
  2. Best Current Practice for OAuth 2.0 Security — IETF (2026-08-03)
  3. The OAuth 2.0 Authorization Framework — IETF (2026-08-03)