IETF · September 2021

OAuth 2.0 Pushed Authorization Requests

RFC 9126

T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. Skokan

RFCStableAuthorizationFoundationField guide

Agent consent screens need more context than a scope string. PAR is how you get that context to the AS without putting a mission description in a query string.

At a glance

Problem: Authorization requests stuffed into a front-channel redirect are large, leak via logs and Referer, and can be tampered with. PAR lets the client POST the request to the AS first and redirect with a short request_uri.
Identity / authn / authz: Protects the integrity and confidentiality of the authorization request. Required or recommended by FAPI 2.0 and by several agent-grant profiles.

Actors

Client
Authorization server
Resource owner user-agent

The gap for agents

Authorization requests stuffed into a front-channel redirect leak via logs and Referer and can be tampered with. Agent consent needs more context than a scope string — RAR JSON, resource lists, mission-like descriptions. PAR lets the client POST that payload to the AS and redirect with a short request_uri.

FAPI 2.0 requires PAR. Several agent-grant profiles recommend it. If your agent would otherwise put authorization_details on a URL, you are in PAR territory.

Actors and trust boundaries

The PAR endpoint is a back-channel client-to-AS call: client authentication applies. The user-agent only sees request_uri and client_id. The RS is not involved. An attacker who steals request_uri still needs the user session at the AS; request_uri is one-time and short-lived.

Mechanics

POST application/x-www-form-urlencoded (or JWT) to the PAR endpoint with the authorization parameters. AS returns request_uri and expires_in. Authorization redirect: client_id + request_uri only. RFC 9126, September 2021.

request_urifrom spec: Quoted RFC 9126: one-time reference to the pushed request. Short-lived.

Step-by-step flows

Flow 1

Push then redirect

1
Client authenticates to the PAR endpoint and POSTs scope, resource, PKCE challenge, authorization_details, redirect_uri, …
2
AS stores the request, returns request_uri.
3
Client redirects the user with client_id and request_uri.
4
AS looks up the request; user authenticates and consents; code issued as usual.

Identity vs authentication vs authorization

Protects integrity and confidentiality of the authorization request. Not user identity. Authorization detail may ride inside (RAR).

How it composes

RAR
PAR is how you transport large authorization_details safely.
JAR
JAR signs the request; PAR hides it from the front channel. Combinable. FAPI 2.0 prefers PAR.
FAPI 2.0
PAR is mandatory; unauthenticated pushed requests are rejected.
OAuth 2.1
Compatible extension; not folded into 2.1 core.
OAuth agent grants
The OAuth agent-grants profile uses PAR + PKCE + resource indicators.

What bites agent implementers

Front-channel fallback
If the AS allows the same parameters on /authorize without PAR, attackers will use that path. FAPI forbids it.
request_uri theft is still a session
Treat request_uri as a capability: one-time, short exp, bound to the client.

Stability — what you can ship

RFC 9126, September 2021. Stable. Ship it. https://www.rfc-editor.org/rfc/rfc9126.html

Catalog claims (short form)

request_uri: One-time reference to the pushed request. Short-lived.

Implementer notes

Use PAR whenever an agent would otherwise put RAR JSON, many scopes, or a rich resource list on a URL.

Relationship to others

Primary sources

RFC 9126https://www.rfc-editor.org/rfc/rfc9126.html