คำขอการมอบสิทธิ์แบบผลัก (PAR)

Normally authorization parameters travel in the browser URL to /authorize. They are visible, can be tampered with, and get long when requests are rich (claims, multiple resources). PAR moves them to a trusted back-channel.

With Pushed Authorization Requests (RFC 9126), the client first POSTs all authorization parameters directly to a new pushed_authorization_request endpoint. The server stores them and returns a request_uri handle.

The client authenticates and sends the parameters server-to-server.

The server validates and stores the request, returning a one-time request_uri plus an expiry.

Now the browser redirect to /authorize carries only the client_id and the request_uri — nothing sensitive in the URL.

Because parameters were pushed over an authenticated TLS channel, the user-agent cannot tamper with them, and they are not exposed in browser history, logs, or referrer headers. This raises assurance significantly.

The PAR endpoint requires the client to authenticate (secret, mTLS, or private_key_jwt). This means the authorization request itself is tied to a verified client before the user ever sees the consent screen.

The request_uri is short-lived (often 60 seconds) and intended for single use. After the authorization request consumes it, it cannot be replayed.

PAR is a building block of FAPI 2.0 and financial-grade security profiles, where front-channel tampering must be eliminated. Many high-assurance deployments mandate PAR for all authorization requests.

Providers advertise PAR via discovery metadata, including pushed_authorization_request_endpoint and optionally require_pushed_authorization_requests to enforce it.

Adopt PAR for confidential clients in regulated or high-value contexts, when requests carry sensitive parameters, or when you want to guarantee request integrity. It pairs naturally with PKCE and mTLS-bound tokens.

Pushed Authorization Requests (RFC 9126) move authorization parameters to a back-channel.

• The client POSTs parameters to the PAR endpoint and gets a request_uri.
• The browser redirect carries only client_id + request_uri.
• This guarantees request integrity/confidentiality and authenticates the client up front.
• PAR is a cornerstone of FAPI-grade security.