2026-09-22 · 6 min read · Rahul Chitturi
- oauth
- security
- debugging
Pushed Authorization Requests let a client send authorization parameters directly to the authorization server before redirecting the browser. The server returns a short-lived request_uri that represents the accepted request.
Failures commonly come from authenticating at the wrong endpoint, changing parameters between steps, reusing an expired handle, or treating request_uri as a URL the client should fetch.
Separate the back channel and redirect
Capture the trusted issuer metadata, PAR endpoint, client authentication method, content type, exact submitted parameters, response status, request_uri, expiry, and later authorization URL. Redact credentials, codes, and live handles.
- Discover endpoints from trusted issuer configuration.
- Send the request using the required form encoding.
- Preserve the returned request_uri exactly.
- Use every handle only according to server policy.
Compare policy at both steps
The PAR endpoint can reject redirect URIs, response types, PKCE values, request objects, resources, or authorization details before a browser is involved. The authorization endpoint can then reject an expired, unknown, reused, or client-mismatched request_uri.
Do not add changed authorization parameters beside request_uri unless the profile explicitly permits them. Keep state correlation and PKCE verifier storage bound to the same browser transaction.
Reproduce without live credentials
Use Flashman's URL tool for synthetic redirect URLs, JWT decoder for disposable request objects, JSON formatter for sanitized metadata, and diff for parameter sets.
Test authentication methods, duplicate parameters, exact redirect matching, PKCE, request-object conflicts, expiry boundaries, retries, browser cancellation, issuer mix-ups, clock skew, and server metadata rotation.