Consider adding support for pushed authorization requests (PAR, RFC 9126)

Expected Behavior

RFC 9126 introduces pushed authorization requests (PAR) for OAuth. In essence, pushed authorization requests allow the client to send authorization request information to the authorization server through back channel communication rather than through the user agent. Not exposing the authorization request data to the user agent makes it harder for an attacker to manipulate said info, e.g. change the requested scopes or tamper with any of the additional query parameters defined in one of the many OAuth enhancement RFCs. Once the client has successfully pushed the authorization request data, the AS responds with a unique identifier that the client must then send as a query parameter during a normal authorization request. From there everything works as usual.

PAR are part of the upcoming FAPI 2.0 and more and more AS/OP products and frameworks such as Keycloak, Forgerock and Nimbus OAuth are adding support for PAR. It would be great if the Spring Security OAuth Client would support PAR out of the box. PAR endpoints can be discovered from the AS/OP published metadata. Ideally it would be as simple as setting a boolean flag in the client configuration to configure the client to use PAR.

Current Behavior

PAR not supported in Spring Security OAuth Client.

Context

Any and all information being transported through the user agent during an authorization request can be manipulated. JWT-Secured Authorization Request (JAR) address this but can lead to quite long query strings which can cause problems with some AS or the web server on which they are hosted. Signed and encrypted JWTs are required to add tamper proofing and confidentiality, respectively. This adds more complexity on the client side. PAR finds a middle ground as it adds a good degree of confidentiality and tamper proofing by not passing the sensitive authorization data through the user agent. For added security, PAR can be combined with JAR to alleviate the long request string problem.

Start with the Spring Security OAuth Client and RFC 9126, then review how authorization-server metadata and authorization requests are currently handled. Done means clients can opt into PAR, discover the PAR endpoint from published metadata, push authorization data through the back channel, and use the returned request URI in the authorization request.