While integrating Pushed Authorization Requests (PAR) with Keycloak, I noticed that the client setting “Request Object Required” is applied to the PAR endpoint in the same way as it is to the authorization endpoint.

This raises a question about RFC 9126 compliance and intended behavior.

Background

According to RFC 9126 §2.1 (Pushed Authorization Requests):

The PAR endpoint:

• Receives authorization request parameters via a direct POST
• MUST NOT accept the request_uri parameter
• MAY include a request object, but it is not required by the spec

The request_uri authorization request parameter is one exception, and it MUST NOT be provided.

At the same time, Keycloak client configuration allows enforcing:

• not required
• request only
• request_uri only
• request or request_uri

These policies make sense for the authorization endpoint, but appear problematic when applied to PAR.

Example

In my local Keycloak instance, I configured the following settings:

After applying these settings, I sent the following Pushed Authorization Request (PAR):

curl --location 'https://<auth-server-host>:<port>/realms/<realm-name>/protocol/openid-connect/ext/par/request' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=<client-id>' \
  --data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
  --data-urlencode 'client_assertion=<client-assertion-jwt>' \
  --data-urlencode 'response_type=code' \
  --data-urlencode 'scope=openid' \
  --data-urlencode 'redirect_uri=https://<application-domain>/callback'

The server responds with the following error:

400
Bad Request

{
    "error": "invalid_request",
    "error_description": "invalidRequestMessage"
}

Discussion Points

I’d like to get feedback from the community and maintainers on:

1. Should the PAR endpoint bypass the client’s request/request_uri enforcement?
2. Should request_uri be explicitly rejected at PAR?
3. Is the current behavior intentional, or an oversight caused by reusing authorization endpoint parsing logic?
4. Would it make sense to treat PAR as a distinct protocol endpoint with its own validation rules?