Wiki · Concept · Last reviewed June 25, 2026

Pushed Authorization Requests

Pushed Authorization Requests are an OAuth 2.0 extension that lets a client send authorization request details directly to the authorization server, then redirect the browser with a short request reference instead of exposing the whole request in the front channel.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, PAR, request_uri, audit trails

Definition

Pushed Authorization Requests, usually abbreviated PAR, are an OAuth 2.0 extension standardized in RFC 9126. The RFC was published in September 2021 by Torsten Lodderstedt, Brian Campbell, Nat Sakimura, Dave Tonge, and Filip Skokan. It defines a pushed authorization request endpoint where an OAuth client can send the payload of an authorization request directly to the authorization server.

The authorization server responds with a request_uri value. The client then redirects the user agent to the ordinary authorization endpoint with that reference, rather than placing the full authorization request in the browser URL. The result is a smaller, less exposed front-channel request.

For AI agents, PAR matters because agent permissions can be detailed, sensitive, and easy to misread. A request involving files, payments, tickets, deployments, or external messages should not depend on a long URL that is visible to browser history, server logs, extensions, and referrer paths.

How It Works

In the base OAuth 2.0 authorization-code flow, the client commonly sends request parameters to the authorization endpoint through a browser redirect. RFC 9126 describes the security and privacy problems with that pattern: request parameters lack front-channel integrity protection, can leak through user-agent paths, and can become too large for reliable processing.

With PAR, the client first sends an HTTP POST request to the authorization server's PAR endpoint. That endpoint must use HTTPS. It accepts ordinary authorization request parameters and applicable extensions such as Proof Key for Code Exchange, resource indicators, Rich Authorization Requests, and optionally JWT-Secured Authorization Requests.

The authorization server can authenticate the client before user interaction. If the pushed request is accepted, the server returns a request_uri and an expiration time. The browser redirect then carries a compact reference, and the authorization server resolves that reference to the stored request.

Agent Context

Agent systems make authorization requests more complicated. A browser assistant may ask to read one inbox thread, a coding agent may request deployment authority, or a finance agent may ask for a narrowly described payment. Those details can involve Rich Authorization Requests, resource indicators, state, redirect URIs, and consent-screen context.

PAR gives agent platforms a cleaner place to assemble those parameters before the user sees the approval step. Instead of routing the whole payload through browser-facing URLs, the client pushes the request to the authorization server over a direct channel. That reduces accidental exposure and lets the authorization server reject malformed or unauthorized client requests early.

This does not solve prompt injection or overbroad delegation. If the legitimate client pushes a dangerous request because an agent was manipulated, PAR only protects how the request travels. Safety still depends on tool policy, approval design, least privilege, and resource-server enforcement.

Governance and Safety

The governance value of PAR is that the authorization server sees the full request before the user-agent redirect. That creates a checkpoint for client authentication, request validation, policy checks, and logging. In high-risk agent workflows, the pushed request should be part of the audit record.

A useful audit trail should preserve the client, pushed request identifier, request_uri, expiration time, requested scopes, resource indicators, authorization details, user approval event, resulting token class, and final resource action. The request_uri is a reference, not a permission slip by itself.

RFC 9126 calls out security concerns including request URI guessing, open redirection, request-object replay, client-policy changes, and request URI swapping. Agent systems should treat those concerns as design requirements, not footnotes. A stale request reference should not authorize a fresh task; a request pushed by one client should not be usable by another.

Defense Pattern

Source Discipline

Claims about Pushed Authorization Requests should identify the PAR endpoint, client authentication method, pushed parameters, request_uri lifetime, and whether the deployment also uses JWT-Secured Authorization Requests or Rich Authorization Requests. PAR should not be confused with OAuth Token Exchange, Rich Authorization Requests, ordinary authorization-code redirects, API keys, or consent as a legal conclusion.

Spiralist Reading

Spiralism reads PAR as a discipline of moving authority through the right channel. The request should not wander through every surface that happens to carry a URL. It should be presented to the authority that can validate it, then shown to the person in a form they can inspect.

The lesson is architectural: when machines ask for power, the path of the ask matters. A cleaner channel is not a moral answer, but it is a better place to attach policy, memory, and refusal.

Open Questions

Sources

Return to Wiki