OAuth 2.0 Pushed Authorization Requests
Extracted elements (28)
HTTP POST to the authorization endpoint via user agent was considered as an alternative for large requests, but is optional per RFC 6749 and is prohibitively difficult for native mobile applications that are constrained by platform APIs to launch browsers via GET. PAR is simpler and provides additional security benefits.
PAR allows authenticated clients to specify 'redirect_uri' values not previously registered, since the authorization server has verified client identity before the authorization process starts. This relaxes the exact matching requirement of the OAuth security BCP while maintaining security through client authentication.
PAR was designed to address three weaknesses of conventional OAuth authorization requests: lack of cryptographic integrity/authenticity protection, no confidentiality for request parameters (query strings leak via user agents, logs, referrers), and URL length limitations causing processing errors in fine-grained authorization scenarios.
The presence of 'pushed_authorization_request_endpoint' in server metadata is sufficient for a client to determine it may use the PAR flow. A 'request_uri' obtained from the PAR endpoint is usable at the authorization endpoint regardless of 'request_uri_parameter_supported' or 'require_request_uri_registration' OpenID Connect Discovery metadata.
Authorization servers SHOULD treat 'request_uri' values as one-time use but MAY allow duplicate requests due to a user reloading/refreshing their user agent.
If the client has authentication credentials established with the authorization server, the authorization server must reject a Request Object where the authenticated 'client_id' does not match the 'client_id' claim in the Request Object.
If the client is required to use signed Request Objects, the authorization server MUST only accept requests complying with Section 3 and MUST refuse any other request with HTTP 400 and error code 'invalid_request'.
If verification is successful, the server MUST generate a request URI and return it with HTTP status code 201. The response uses application/json media type and includes 'request_uri' and 'expires_in' fields.
The authorization server MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as valid audience values for JWT client assertion-based authentication at the PAR endpoint. The issuer identifier URL SHOULD be used as the audience.
The authorization server MUST authenticate the client at the PAR endpoint using the same rules as for the token endpoint, validate that 'request_uri' is absent, and validate the pushed request as it would an authorization request.
The authorization server MUST only accept new redirect URIs in the pushed authorization request from authenticated clients.
The authorization server MUST validate authorization requests arising from a pushed request as it would any other authorization request. Authorization server policy MAY require PAR as the only means of passing authorization request data, refusing requests without a PAR-obtained 'request_uri' with 'invalid_request'.
The client MUST only use a 'request_uri' value once since authorization request content (e.g., 'code_challenge') is unique per request. An expired 'request_uri' MUST be rejected as invalid.
The PAR endpoint URL MUST use the 'https' scheme.
The 'request_uri' authorization request parameter MUST NOT be provided in a pushed authorization request.
The 'request_uri' value MUST contain a cryptographically strong pseudorandom component such that it is computationally infeasible to predict or guess a valid value, and MUST be bound to the client that posted the authorization request.
When using JAR Request Objects in PAR, all authorization request parameters MUST appear as claims of the JWT; only client authentication parameters may appear outside the 'request' JWT in the form body.
PAR improves privacy by passing authorization request data directly between client and authorization server over a secure connection in the HTTP request body, rather than in the URL query string that passes through the user agent in the clear and may leak to web server logs or referrer headers.
PAR error responses use the same format as token endpoint errors (RFC 6749 Section 5.2). Additional HTTP status codes 405 (Method Not Allowed), 413 (Payload Too Large), and 429 (Too Many Requests) are defined for PAR-specific conditions.
The authorization server MAY construct the 'request_uri' using the form 'urn:ietf:params:oauth:request_uri:<reference-value>' where the reference-value is the random part. A registered URN sub-namespace is established for this purpose.
The PAR endpoint is an HTTP API accepting POST requests with authorization request parameters in application/x-www-form-urlencoded format. The PAR endpoint URL MUST use the 'https' scheme.
The 'pushed_authorization_request_endpoint' authorization server metadata parameter identifies the URL of the PAR endpoint. The 'require_pushed_authorization_requests' boolean parameter (default: false) indicates whether the server accepts authorization requests only via PAR.
The 'require_pushed_authorization_requests' client metadata parameter (default: false) indicates whether the client is required to use PAR as the only means of initiating authorization requests.
The successful PAR response contains 'request_uri' (a single-use URI referencing the pushed authorization data) and 'expires_in' (a positive integer lifetime in seconds, typically between 5 and 600 seconds), returned as JSON with HTTP 201.
IANA 'OAuth Authorization Server Metadata' registry updated with 'pushed_authorization_request_endpoint' and 'require_pushed_authorization_requests' parameters. 'OAuth Dynamic Client Registration Metadata' registry updated with 'require_pushed_authorization_requests'. 'OAuth URI' registry updated with 'urn:ietf:params:oauth:request_uri:' URN sub-namespace.
An attacker could attempt to guess and replay a valid request URI to impersonate a client. The authorization server MUST account for JAR Section 10.2(d) on request URI entropy, requiring cryptographically strong pseudorandom values.
An attacker could capture a request URI from one authorization request and substitute it into a different one (e.g., downgrading authentication assurance level). Clients SHOULD use PKCE, a unique 'state' parameter, or the OIDC 'nonce' parameter in the pushed Request Object to prevent this attack.
Client policy might change between lodging a Request Object and the authorization request using it. It is recommended that the authorization server check request parameters against client policy when processing the authorization request at the authorization endpoint.