A pushed authorization request (PAR) is an OAuth mechanism that moves an authorization request object to the authorization server before the user-facing authorization redirect. The client sends a signed JWT over an authenticated request, receives a unique request URI, and redirects the user agent using that URI. section 10.4 section 10.5
PAR reduces the exposure and manipulation of authorization parameters. Ordinary authorization URLs can leak client data into network logs, be observed by eavesdroppers, or be forged to alter the redirect_uri, steal authorization codes, or support CSRF attacks. Authentication lets the authorization server distinguish a legitimate pushed request from a forged one. section 10.5 section 10.7
A typical PAR exchange follows these steps:
- Build the authorization request object with values such as response_type, client_id, redirect_uri, scope, state, and nonce. section 10.5
- Sign the request object as a JWT using the client's private key, proving the request's integrity and origin. section 10.5
- Push the signed request object to the authorization server through an authenticated request. section 10.7
- Receive a unique request URI and place it in the user-facing authorization request's request_uri parameter. section 10.5
From exposed parameters to PAR
Instead of sending /authorize?response_type=code&client_id=s6BhdRkqt3&redirect_uri=https://example.com, the client signs the complete request object, pushes it to the authorization server, receives a unique request URI, and redirects the user agent with request_uri. The browser-facing URL then carries the reference rather than the full authorization request.
