Use Pushed Authorization Requests (PAR) and Rich Authorization Requests (RAR).
Pushed Authorization Requests (PAR) move authorization details to a direct client-to-server request before the browser redirect. Rich Authorization Requests (RAR) let a client describe structured access needs instead of relying only on short scope strings.
Why this lesson?
A payment application needs to request approval for one specific transaction while keeping the detailed authorization request out of an editable browser address.
Learning goal and prerequisites
Push the authorization request
The client sends the authorization request parameters directly to the authorization server’s Pushed Authorization Request (PAR) endpoint over Hypertext Transfer Protocol Secure (HTTPS). The request can include Proof Key for Code Exchange (PKCE), OpenID Connect data, and structured authorization details.
Inspect request, response, and claims
Try a failure scenario
↳ Change a condition
Read the detailed explanation
Why it exists, how it works, and where it fits
Some authorization requests contain more detail than a short scope string can express, and some of that detail should not travel through an editable browser address. Pushed Authorization Requests (PAR) and Rich Authorization Requests (RAR) solve different parts of that problem and are often useful together.
With PAR, the client sends the full authorization request directly to the authorization server over a protected back-channel first. The server stores the request and returns a short request reference. The browser carries that reference instead of carrying every sensitive or security-critical parameter.
RAR improves what the request can say. Instead of asking only for a broad scope such as payments, the client can send structured authorization details for a particular transaction, account, amount, or action. That gives the authorization server more information for policy and clearer user approval.
PAR protects the delivery of the authorization request. RAR improves the meaning of the requested access. Neither one replaces client authentication, redirect validation, Proof Key for Code Exchange, user authentication, or consent. They strengthen the authorization request while the rest of the OAuth flow still performs its own checks.
Investigation
Inspect the traffic, select a diagnosis in the checkpoint, then reveal the repair.
Check your understanding
Pass the lesson quiz
Answer every question correctly to unlock the next lesson. Retry as often as you need.