Pushed authorization requests (PAR, RFC 9126) let an OAuth client send the details of its authorization request directly to the authorization server over a back channel, and get back a short reference to use in the browser redirect. It protects request integrity and confidentiality, which matters for payments and regulated data.
The problem it fixes
In a normal OAuth flow the app sends the user to the authorization endpoint with parameters in the URL query string. RFC 9126 lists three weaknesses of that approach:
- There is no cryptographic integrity or authenticity protection. An attacker could change the requested scope, or swap the context of a payment, by editing parameters.
- There is no confidentiality for the parameters. They pass through the user agent in the clear and can leak into web server logs and, through the referrer, to other sites. That is significant when personal or regulated data is in the request, as in identity and open banking.
- Request URLs can grow large when fine grained authorization data is needed, which can cause processing errors.
How PAR works
- The client sends a POST to the authorization server's PAR endpoint with the same parameters it would have put in the URL, plus its client authentication.
- The server validates the request and the client before any user interaction.
- The server returns a request_uri, a reference to the stored request, and an expires_in value. RFC 9126's examples show lifetimes of 60 and 90 seconds.
- The client redirects the user to the authorization endpoint with only the client ID and the request_uri.
- The server looks up the stored request and continues the flow as usual.
The sensitive details never travel through the browser or its history.
Why mobile and partner apps care
RFC 9126 points out that sending the request as a POST through the user agent is hard for installed mobile apps. Per RFC 8252, those apps open the authorization request URL in the system browser using platform APIs, which means the initial request is a GET carrying everything in the URL. PAR gives them a way to keep the details out of that URL.
Another benefit is early client authentication. The server can authenticate the client before any user interaction and refuse spoofed or tampered requests early.
When PAR is worth it
| Situation | PAR useful? |
|---|---|
| Payments, open banking or other high value flows | Yes, request tampering has real cost |
| Requests carrying personal data or fine grained authorization details | Yes, keeps them out of URLs and logs |
| Very long authorization requests | Yes, avoids URL length limits |
| Simple sign in with a few standard scopes | Optional |
| Client that cannot authenticate to the server | Limited benefit |
PAR complements other mechanisms. PKCE still protects the code exchange, and JWT secured authorization requests can be combined with PAR if you need signed requests and non repudiation.
What to check before you adopt it
- Does your authorization server support a PAR endpoint, and can it require PAR for specific clients?
- Can your client library push requests and use request_uri?
- Do you log PAR request bodies anywhere? They carry the same data you were trying to keep out of URLs.
- Is the request_uri single use and short lived on your server? It should be, since it references a stored request.
- Have you updated redirect URI validation and the other checks in your OAuth threat model?
Safeguard's asset discovery helps you find API hosts and versions you may have lost track of, and its SBOM and dependency scanning shows which libraries ship in your builds. You can start with the free scan at gold.safeguard.sh/scan.
Quick check
Does PAR replace PKCE?
No. PAR protects the authorization request. PKCE protects the authorization code from interception. Many deployments use both.
Is the request_uri a secret?
Treat it as a short lived, single use reference. It is sent through the browser, so it should not be reusable by anyone who sees it.
Sources
Last reviewed: 19 October 2026.
