Pushed authorization request (PAR)
Sending OAuth request parameters to the server directly, not through the browser.
A pushed authorization request (PAR, RFC 9126) sends an OAuth authorization request’s parameters straight to the authorization server in an authenticated back-channel call, instead of through the user’s browser. The server returns a short-lived request_uri, and the client redirects the user with only its client_id and that request_uri, so the request cannot be read or altered on the way.
PAR lets the server authenticate the client and check the whole request before the user sees a consent screen, and it keeps long or sensitive parameters out of URLs and browser history. FAPI 2.0 requires it.
Worked example
A client posts response_type=code, its redirect_uri, scope, state and PKCE code_challenge to the PAR endpoint with its client authentication, and receives a request_uri such as urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c with expires_in 60. It then sends the user to the authorization endpoint with client_id and that request_uri alone.
Common mistake
Letting a request_uri live long or be used twice. It is meant to be short-lived and used once, and the authorization server should check that the client presenting it is the client that pushed it.
Grounded in IETF — RFC 9126, OAuth 2.0 Pushed Authorization Requests guidance. Figures last checked . General information, not tax advice.
Related terms
FAPI 2.0
The OpenID Foundation’s high-security OAuth profile for financial APIs.
DPoP (Demonstrating Proof of Possession)
An OAuth method that binds a token to a key the client holds.
ISO 20022
The international standard for financial messages — payments, statements and more.
camt.053 (ISO 20022 bank statement)
The end-of-day bank statement in ISO 20022 XML.
← Back to the full glossary.
Questions about this term
Pushed authorization request (PAR): common questions
- Why use a pushed authorization request instead of a normal redirect?
- A normal redirect carries every parameter through the browser, where it can be read, logged or tampered with, and the server only meets the client at the token step. With PAR the server authenticates the client and checks the full request first, and the browser carries nothing but a reference.
- Is PAR the same as a request object (JAR)?
- No. A request object (JAR, RFC 9101) signs the parameters into a JWT, which can still travel through the browser. PAR sends the parameters to the server over a back channel, and the two can be combined by pushing a signed request object.
- Does PAR work with PKCE?
- Yes, and they are usually used together: the code_challenge is pushed with the other parameters, and the client later proves it with the code_verifier at the token endpoint. FAPI 2.0 requires both of them.
Let Fin handle the jargon for you
Connect your bank and Fin sorts your income, expenses and GST automatically — so terms like this just become numbers that are already worked out. Free to start, no card needed.
Get 2Fin free →
