Pushed Authorization Requests (PAR) in the AuthPlayground
Establishing the authorization request before the browser redirect.
Sarah asks the AI assistant to prepare her for the Apex Logistics meeting. Before an application can access protected information on Sarah’s behalf, it might need to send an OAuth authorization request.
In a traditional OAuth flow, an application sends authorization parameters (such as client_id, redirect_uri, requested scopes, Proof Key for Code Exchange (PKCE) challenge, state, and potentially richer authorization information) through the browser to the authorization server. PAR (RFC 9126) changes this dynamic.
The PAR model
Instead of passing the full request through the browser, with PAR the client sends these parameters directly to the authorization server before the browser redirect begins. The authorization server validates and stores the request, returning a short-lived reference called a request_uri. The browser carries only this reference, instead of sensitive authorization details. This is the PAR flow:
-
The client sends the full authorization request to the PAR endpoint.
-
The PAR endpoint returns a
request_urito the client. -
The browser carries the
request_urito the authorization endpoint.
Why this matters for enterprise AI
AI can change is the richness of the authorization request. An AI workflow might need to request a particular set of resources or permissions. If Rich Authorization Requests (RAR) are also being used, the request might contain structured authorization_details describing a specific operation.
As requests become richer, establishing them directly with the authorization server becomes useful. The browser still participates in the user-facing authorization flow, but it doesn’t need to carry the complete authorization request.
The AuthPlayground implementation
Entities involved: Client application, IdP (authorization server)
The AuthPlayground demonstrates the Pushed Authorization Requests flow in three steps:
-
Push the authorization request to the PAR endpoint.
-
Send the authorization request with the
request_urithrough the browser. -
Exchange the authorization code at the token endpoint.
Step 1: Push the authorization request
The client sends the authorization request parameters directly to the PAR endpoint:
POST /idp/par
Content-Type: application/x-www-form-urlencoded
client_id=playground-demo-client
client_secret=playground-demo-secret
redirect_uri=https://.../callback
response_type=code
scope=openid profile email
state=<state>
code_challenge=<pkce_challenge>
code_challenge_method=S256Notice that the client communicates directly with the authorization server rather than placing these parameters in the browser-facing authorization URL. The playground uses client authentication at the PAR endpoint through client_id and client_secret. PKCE is already part of the request.
The authorization server processes the pushed request and returns:
{
"request_uri": "urn:ietf:params:oauth:request_uri:515c113d-0b97-4453-b52f-42d2dbac0b1b",
"expires_in": 60
}The important value is request_uri. It’s a short-lived reference to the authorization request the server has already received. In the playground flow, the reference expires after 60 seconds.
Step 2: Send the request_uri through the browser
The client can now start the user-facing authorization flow. Instead of reconstructing the original authorization request in the URL, it sends only the request_uri and client_id:
GET /idp/authorize
request_uri=urn:ietf:params:oauth:request_uri:515c113d-0b97-4453-b52f-42d2dbac0b1b
client_id=playground-demo-clientCompare the direct PAR request with the browser request. The direct request contained:
client_id client_secret redirect_uri response_type scope state code_challenge code_challenge_method
The front-channel browser request is now essentially the request_uri and client_id.
The authorization server uses the request_uri to retrieve the authorization request established in Step 1. After the user-facing authorization process succeeds, the server redirects back to the registered callback with an authorization code and the original state. This is the key change PAR introduces: the authorization request is established directly with the authorization server before the browser redirect.
Why the request_uri matters
The request_uri is more than just a shorter URL. It refers to authorization parameters that the authorization server has already received and processed through the PAR endpoint. This reduces reliance on the browser to carry the full authorization request and gives the authorization server an opportunity to validate the pushed parameters before user interaction proceeds. RFC 9126 also requires the request_uri returned by the PAR endpoint to be bound to the client that pushed the authorization request.
Step 3: Exchange the authorization code
Once authorization succeeds, the client exchanges the authorization code at the token endpoint. The playground uses PKCE:
POST /idp/token
Content-Type: application/x-www-form-urlencoded
{
"grant_type": "authorization_code",
"code": "<authorization_code>,
"redirect_uri": "https://.../callback",
"client_id": "playground-demo-client",
"code_verifier": "<code_verifier>"
}The authorization server verifies the authorization code and the PKCE verifier before issuing tokens. The playground returns an access token and ID token:
{
"token_type": "Bearer",
"expires_in": 3600,
"scope": "openid profile email",
"access_token": "<access_token>",
"id_token": "<id_token>"
}PAR has already done its job by this point. The token request itself is the familiar Authorization Code flow with PKCE. What changed was how the authorization request reached the authorization server.
How PAR relates to other concepts
PAR and PKCE protect different parts of the flow
The playground makes the relationship between PAR and PKCE easy to see:
-
PAR establishes the authorization request directly with the authorization server.
-
PKCE protects redemption of the authorization code.
In Step 1, the client pushes a code_challenge. In Step 3, the client presents the corresponding code_verifier. The same flow gets protection at two different points. PAR protects the authorization request itself, while PKCE protects the authorization code redemption. PAR and PKCE are complementary, rather than alternatives.
PAR and RAR work together naturally
RAR can make an authorization request more expressive. Instead of requesting only a simple scope such as customer.read, an application can use authorization_details to describe a specific operation:
{
"type": "customer_information",
"actions": ["read"],
"identifier": "apex-logistics"
}PAR provides a natural way to deliver a request containing that richer authorization information directly to the authorization server.
The PAR playground flow doesn’t include authorization_details and that’s okay. PAR doesn’t depend on RAR, but they work well together when an authorization request contains richer information.
A supporting protocol for enterprise AI
Return to Sarah’s meeting preparation. Suppose the AI assistant needs authorization to retrieve customer information. Without PAR, the browser-facing authorization request might need to carry the parameters describing that authorization.
With PAR, the application first establishes the request directly:
-
The AI assistant sends authorization parameters directly to the authorization server.
-
The authorization server returns a
request_uri. -
Sarah’s browser sends the
request_urito the authorization server.
Sarah still goes through the normal user-facing authentication and authorization experience. PAR changes what happens before that interaction. The detailed authorization request between the client and the authorization server has already been established.
PAR is an OAuth security mechanism, not an AI-specific protocol. The same pattern can protect authorization requests for traditional web applications, financial applications, mobile applications, and other OAuth clients.
PAR’s relevance to enterprise AI comes from the same reason it’s useful elsewhere: clients increasingly need to send security-sensitive or detailed authorization requests. These requests benefit from being established directly with the authorization server. AI gives us another environment where richer authorization flows are likely to appear.