Add Pushed Authorization Requests (RFC 9126) Support

[nandhu-kumar]

---

Pushed Authorization Requests

RFC 9126 — Pushed Authorization Requests (PAR) allows OAuth 2.0 clients to push authorization request parameters directly to the authorization server over a back-channel and receive a request_uri in return. The client then redirects the user to the authorization endpoint with just the client_id and request_uri, keeping sensitive parameters out of the browser.

Changes Required in Thunder

New PAR Endpoint

Introduce a POST /oauth2/par endpoint that:

• Accepts all standard authorization request parameters as application/x-www-form-urlencoded form data.
• Authenticates the client using the same method configured for the token endpoint.
• Validates the request (redirect URI, scopes, grant type permissions) the same way the authorization endpoint does.
• Rejects requests that include a request_uri parameter.
• Returns 201 Created with a JSON body containing request_uri (cryptographically random, single-use) and expires_in.
• Returns standard OAuth 2.0 error responses (400, 405, 413, 429) on failure.

Request URI Storage

Store pushed authorization request data keyed by the generated request_uri. Each entry must track:

• The full set of authorization parameters.
• The authenticated client_id.
• An expiration timestamp.
• Single-use enforcement.

Authorization Endpoint Changes

Modify the /oauth2/authorize handler to:

• Detect the presence of a request_uri query parameter.
• Look up the stored request data, verify the client_id matches, check expiration, and mark the URI as used.
• Merge the stored parameters into the authorization request and continue the existing flow.
• Reject the request with invalid_request if the URI is expired, already used, or bound to a different client.
• When PAR is enforced (per-client or globally), reject authorization requests that lack a request_uri.

Discovery Metadata

Add two fields to the OAuth 2.0 Authorization Server Metadata (/.well-known/oauth-authorization-server) response:

• pushed_authorization_request_endpoint — the PAR endpoint URL.
• require_pushed_authorization_requests — boolean indicating whether PAR is mandatory (defaults to false).

Questions

• Per-client vs. global enforcement: Should require_pushed_authorization_requests be configurable at both the application level and the deployment level? If both are set, does the stricter setting (application-level enforce) win, or does the global setting override?
  eSignet support both client level and deployment level configuration, with the stricter setting taking precedence. If either the client or deployment requires PAR, then PAR is enforced for that client.
• Request URI lifetime: What should the default expires_in value be? RFC 9126 suggests short lifetimes (e.g., 60 seconds).
• Public client support: RFC 9126 allows public clients (no client secret) to use PAR. Should Thunder support this from the start, or limit PAR to confidential clients initially? Public client not supported in PAR.
• Client authentication methods: Should the PAR endpoint support all client authentication methods configured for the token endpoint, or only a subset (e.g., private_key_jwt)?
• Any changes to gate application applicable?
• Clients for which PAR is not mandated can they initiate authorization with a PAR request.

[thiva-k]

Hi @nandhu-kumar

Public client support: RFC 9126 allows public clients (no client secret) to use PAR. Should Thunder support this from the start, or limit PAR to confidential clients initially?
Client authentication methods: Should the PAR endpoint support all client authentication methods configured for the token endpoint, or only a subset (e.g., private_key_jwt)?

For the initial implementation, shall we not do any additional changes, validations or special-casing for the PAR initialized flows compared to the usual front-channel flow?

Any changes to gate application applicable?

Gate app/sdk shouldn't have any changes since the authorization flow redirection from backend->gate and the authentication callback will remain the same.

Per-client vs. global enforcement: Should require_pushed_authorization_requests be configurable at both the application level and the deployment level? If both are set, does the stricter setting (application-level enforce) win, or does the global setting override?
eSignet support both client level and deployment level configuration, with the stricter setting taking precedence. If either the client or deployment requires PAR, then PAR is enforced for that client.

+1 to have this.

Clients for which PAR is not mandated can they initiate authorization with a PAR request.

IMO, any client should be able to initialize with PAR. The config should only mandate whether the PAR is must.

[anushasunkada]

@nandhu-kumar

IMO, we should not restrict this to specific client authentication method.

Client authentication methods: Should the PAR endpoint support all client authentication methods configured for the token endpoint, or only a subset (e.g., private_key_jwt)?

But what we will need is a way to restrict the supported client_authentication_methods at deployment. So that it is easier to run the authorisation server with strict adherence to security profiles.

Public client support

If the client is marked as public, it is assumed that secrets cannot be kept by the client (mobile, SPA) or might not even register with JWKS. So it's better to reject PAR by public clients.

[anushasunkada]

As per discussion with thunder team, we have decided not to restrict PAR for public clients. PAR will follow the same client authentication method as of token endpoint. if token endpoint client authentication method is set to NONE then implementation processes PAR without client authentication(This also aligns with the RFC).