4. Authorization Request

4. Authorization Request

The client uses the request_uri value returned by the authorization server to build an authorization request as defined in [RFC9101]. This is shown in the following example where the client directs the user agent to make the following HTTP request (extra line breaks and indentation for display purposes only):

GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams
 %3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1
Host: as.example.com

Since parts of the authorization request content, e.g., the code_challenge parameter value, are unique to a particular authorization request, the client MUST only use a request_uri value once. Authorization servers SHOULD treat request_uri values as one-time use but MAY allow for duplicate requests due to a user reloading/refreshing their user agent. An expired request_uri MUST be rejected as invalid.

The authorization server MUST validate authorization requests arising from a pushed request as it would any other authorization request. The authorization server MAY omit validation steps that it performed when the request was pushed, provided that it can validate that the request was a pushed request and that the request or the authorization server's policy has not been modified in a way that would affect the outcome of the omitted steps.

Authorization server policy MAY dictate, either globally or on a per-client basis, that PAR be the only means for a client to pass authorization request data. In this case, the authorization server will refuse, using the invalid_request error code, to process any request to the authorization endpoint that does not have a request_uri parameter with a value obtained from the PAR endpoint.

Note: Authorization server and clients MAY use metadata as defined in Sections 5 and 6 to signal the desired behavior.