Category: OAuth & OIDC
Pushed Authorization Requests
Also known as: PAR, OAuth 2.0 Pushed Authorization Requests
Simply put
Pushed Authorization Requests (PAR) is an extension to the OAuth 2.0 authorization framework that changes how an application starts an authorization flow. Instead of putting all the request details into the browser redirect where they could be seen or tampered with, the application first sends those details directly to the authorization server over a secure back-channel connection. The server stores the request and gives back a short reference that the application then uses in the browser redirect.
Formal definition
PAR, defined in RFC 9126, is an OAuth 2.0 extension that introduces a pushed authorization request endpoint on the authorization server (AS). Rather than transmitting authorization request parameters through the front-channel via query parameters on the authorization endpoint redirect, the client POSTs the authorization request payload directly to the AS over a direct back-channel request. The AS validates and stores the payload and returns a request URI (typically a short, opaque reference) that the client subsequently supplies to the authorization endpoint when redirecting the user agent. This moves the request payload off the front channel, which reduces exposure to inspection or tampering of authorization request parameters. As an OAuth 2.0 extension, PAR concerns the delegated authorization request flow; it can be used with OpenID Connect, which layers authentication on top of OAuth 2.0. Availability and specific behavior depend on AS support and configuration.
Why it matters
In a standard OAuth 2.0 authorization code flow, the client places authorization request parameters, such as scope, client identifier, redirect URI, and any request-specific data, into the front-channel redirect that passes through the user's browser. Because these parameters traverse the user agent as query parameters, they are exposed to inspection and potential tampering before the request reaches the authorization server. PAR, defined in RFC 9126, addresses this by moving the request payload off the front channel: the client submits it directly to the authorization server over a back-channel connection and receives a short, opaque request URI to use in the subsequent redirect. This reduces the attack surface associated with manipulating or observing authorization request parameters in transit through the browser.
Who it's relevant to
Security architects
Architects designing OAuth 2.0 and OpenID Connect flows can use PAR to move authorization request parameters off the front channel, reducing exposure to inspection and tampering in the browser redirect. It is a relevant control to consider when threat models include manipulation of authorization request parameters, and when adopting profiles that call for stronger request integrity. Its use depends on authorization server support, so it should be evaluated as one option rather than a universally available guarantee.
IAM and identity platform engineers
Engineers integrating clients with an authorization server need to know whether the AS exposes a pushed authorization request endpoint and how to configure clients to POST the payload back-channel and then redirect with the returned request URI. Products such as PingFederate expose a PAR endpoint that must be explicitly enabled, and libraries like OpenIddict provide PAR support, so implementation details and endpoint availability vary by platform.
Compliance and assurance leads
For teams working against higher-assurance requirements or profiles layered on OAuth 2.0, PAR provides a mechanism to ensure the authorization request the user authorizes is the validated payload the client pushed, rather than one potentially altered in the front channel. Whether it is required or merely recommended depends on the specific profile and regulatory context in scope.
Standards and interoperability specialists
Those tracking OAuth 2.0 extensions should note PAR is defined in RFC 9126 and is designed to work with both OAuth 2.0 delegated authorization and OpenID Connect authentication flows. Because behavior, including request URI lifetime and validation, depends on the authorization server, interoperability testing against target implementations is advisable.
Inside PAR
Front-Channel to Back-Channel Shift
PAR moves the authorization request parameters out of the browser front-channel and into a direct, back-channel POST from the client to the authorization server, typically over TLS. This avoids exposing request parameters in the browser address bar, redirects, or logs.
PAR Endpoint
A dedicated authorization server endpoint (the pushed authorization request endpoint) at which the client submits its authorization request parameters directly. The client authenticates to this endpoint, so requests are typically bound to an authenticated client identity.
request_uri Reference
In response to a successful push, the authorization server returns a request_uri that acts as an opaque reference to the stored request. The client then uses this request_uri in the subsequent front-channel authorization request instead of sending the full parameter set.
expires_in / Lifetime
The PAR response typically includes an expiration value indicating how long the returned request_uri remains valid, limiting the window in which the referenced request can be consumed.
Client Authentication
Because the PAR endpoint is a back-channel endpoint, clients generally authenticate when pushing requests (for example via client_secret or private_key_jwt, depending on configuration), which strengthens assurance that the request originated from the legitimate client.
Relationship to OAuth 2.0 and OIDC
PAR is an OAuth 2.0 mechanism that hardens the authorization request stage of the delegated authorization framework. It applies equally to OpenID Connect flows that build on OAuth 2.0, since OIDC authentication requests are carried as OAuth authorization requests.
Common questions
Answers to the questions practitioners most commonly ask about PAR.
Does PAR authenticate the user or replace the need for user authentication at the authorization server?
No. PAR is not an authentication mechanism and does not change how or whether a user is authenticated. It only changes how the client submits authorization request parameters to the authorization server: instead of passing them through the browser front channel, the client pushes them directly to a back-channel PAR endpoint and receives a request URI reference to use at the authorization endpoint. User authentication still occurs at the authorization endpoint as it normally would, according to the authorization server's configuration. PAR secures the delivery and integrity of the request parameters; it does not verify who the user is.
Is PAR the same thing as PKCE, or does one make the other unnecessary?
They are distinct mechanisms that address different parts of the flow, and one does not replace the other. PKCE protects against authorization code interception by binding the code exchange to a client-generated secret. PAR protects the authorization request parameters themselves by moving them to a back channel so they cannot be inspected or tampered with in the front channel. Depending on the profile and deployment, they are frequently used together; PKCE parameters can be included in the pushed request. Using PAR does not remove the value of PKCE, and using PKCE does not provide the request-parameter protection that PAR is designed for.
How does a client use the request_uri returned by the PAR endpoint?
After the client pushes its authorization request parameters to the PAR endpoint over the back channel, the authorization server responds with a request_uri (a reference handle) and, typically, an expiration value. The client then redirects the user agent to the authorization endpoint supplying that request_uri along with its client identifier, rather than sending the full set of authorization parameters in the URL. The authorization server resolves the reference to the previously stored request. Exact parameter naming and required accompanying values depend on the specification profile and the authorization server's configuration.
How should the short-lived nature of the request_uri be handled in implementation?
The request_uri reference is generally intended to be short-lived and, in most deployments, single-use, with a server-defined expiration returned alongside it in the PAR response. Clients should redirect the user to the authorization endpoint promptly rather than caching the reference for later reuse, and should be prepared to handle an expired or already-consumed reference by initiating a new PAR request. The specific lifetime and whether reuse is permitted are determined by the authorization server, so implementers should verify behavior against their provider's documentation rather than assuming a fixed value.
What authentication is required for the client at the PAR endpoint?
Because the PAR endpoint is a back-channel endpoint, client authentication is typically applied there in the same manner the authorization server requires for other back-channel endpoints such as the token endpoint, depending on the client type and configuration. Confidential clients generally authenticate using their configured method, while public clients may submit requests without a client secret depending on the profile in use. The precise client authentication requirements are set by the authorization server and the applicable profile, so implementers should confirm which methods are supported and mandated for their client registration.
When does adopting PAR provide the most practical benefit?
PAR is most useful where front-channel exposure of authorization request parameters is a concern, such as when requests carry sensitive parameters, when request integrity must be assured against tampering in the browser, or where a higher-assurance profile calls for it. It is also relevant when request sizes become impractical to pass as URL parameters, since the back-channel push avoids browser URL length constraints. Whether PAR is required or merely recommended depends on the security profile and the authorization server's configuration; confirm the applicable profile's expectations before treating it as mandatory.
Common misconceptions
PAR authenticates the end user or replaces user authentication.
PAR does not authenticate the end user. It secures how the client submits the authorization request to the authorization server. User authentication still occurs at the authorization server as part of the flow, and in OpenID Connect it is OIDC, layered on OAuth 2.0, that provides user authentication, not PAR itself.
The request_uri returned by PAR is a token that grants access.
The request_uri is an opaque, typically short-lived reference to a previously stored authorization request. It is not an access token, ID token, or refresh token, and it does not by itself confer any access; it only points the front-channel request to the parameters already pushed to the server.
PAR encrypts the authorization request end to end.
PAR primarily moves request parameters to a back-channel and returns a reference, relying on the transport (typically TLS) for confidentiality in transit. Keeping parameters off the front-channel is not the same as encrypting the request payload itself; PAR should not be assumed to provide message-level encryption unless combined with mechanisms that do so.
Best practices
Enforce client authentication at the PAR endpoint so that pushed requests are bound to a verified client identity, using a method (such as private_key_jwt) appropriate to your assurance requirements and vendor support.
Keep request_uri lifetimes short and treat the reference as single-use where the authorization server supports it, to reduce the window for replay or interception.
Require or prefer PAR for high-assurance and sensitive clients so authorization request parameters are not exposed in browser URLs, redirects, or logs.
Serve all PAR interactions over TLS, since PAR relies on transport security for confidentiality in transit and does not by itself encrypt the request payload.
Confirm that your authorization server profile and client libraries support PAR before mandating it, since behavior and availability vary by vendor and deployment configuration.
Where you need cryptographically integrity-protected requests, evaluate combining PAR with signed request objects rather than assuming PAR alone signs or encrypts the request.
