RFC 9126 / START HERE
Pushed authorization, before the details
PAR means Pushed Authorization Requests, an extension to the OAuth2.0 authorization framework.
A client sends its authorization request directly to the authorization server over HTTPS. The server returns a short-lived reference, which the client then sends through the browser to begin normal authorization.
The idea in one picture
Push request details
Receive a short-lived reference
Continue in the browser
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Large or sensitive request details need not travel in the browser URL. PAR provides a direct delivery path and early validation; it does not itself grant permission, issue a token or replace other OAuth safeguards.
A familiar example
A calendar app pushes its requested scopes and callback before opening a browser. The browser carries a request reference; the server still checks the client, lifetime and authorization requirements.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Push first, then open the browserThe client sends request details directly to the authorization server; the browser later carries a reference to those details.→
- Read the pushed form and its responseA UTF-8 form carries authorization parameters; a successful JSON response gives the bound reference and its lifetime.→
- Resolve only a matching, live referenceThe browser returns the server-issued reference; client binding, expiry and use rules constrain it.→
- Reject early and preserve redirect policyA failed push returns a direct error; checks that cannot run yet and redirect exceptions have precise limits.→
- Discover PAR and keep transaction safeguardsMetadata signals capability and requirement; Request Objects and transaction checks remain separate protections.→
This introduction explains RFC 9126 (2021). Read the original RFC ↗