OAuth2 Pushed Authorization Request request_uri expiry is too short

[said026]

Expected Behavior
The expires_in field in the PAR (Pushed Authorization Request) endpoint should be configurable, allowing flexibility to adjust the duration based on specific deployment needs.

Current Behavior
The expires_in value is currently hardcoded to 30 seconds (cf OAuth2PushedAuthorizationRequestUri.java), this is limiting and resulting in a very short window for users to finalize the authorization flow.

Context
This limitation affects user experience by providing only 30 seconds to finalize the authorization flow after generating the PAR.

Additional note
At the end of the authorization process, the user is redirected back to the initial /authorize request (e.g.,
http://localhost:8080/oauth2/authorize?client_id=my-client-id&request_uri=urn:ietf:params:oauth:request_uri:g3uYrr-vcFsPlKTvGMmaIAAJUClbQLAoCiAQebp2lII=___1747987199473).
At this stage, the request_uri is validated again, so it must not be expired.

This behavior is due to Spring Security's flow, which redirects back to /authorize at the end of the authentication process.
However, this second validation might not be compliant with RFC 9126, The RFC is unclear whether the expires_in parameter relates to the time between the initial /par request and the first /authorize call (which consumes the request_uri), or if it concerns the total duration of completing the entire authorization flow.

[jgrandja]

@said026 I'm trying to understand your use case. I would expect 30 secs to be long enough for the expires_in from the point the client receives the request_uri from the PAR endpoint to the point it sends it to the Authorization endpoint.

However, if I'm understanding your use case correctly, it seems the user is NOT authenticated when the client redirects to the Authorization endpoint and the authentication process is taking longer than 30 secs (e.g. MFA steps) and therefore the request_uri expires before it's redirected back to the Authorization endpoint the 2nd time (after the user successfully authenticates). Did I understand your use case correctly?

[said026]

Thank you @jgrandja for your reply.

Exactly, as you stated, the expires_in of the request_uri spans the entire process, including the second redirection to /authorize which performs an additional check of the expires_in through OAuth2AuthorizationCodeRequestAuthenticationProvider

[edouardhue]

I suspect this is an unwanted behavior that might have been overlooked. After Spring Security authenticates the user, it redirects them back to the "saved request" (which is the original Authorization Request including a request_uri). The Authentication endpoint then restarts the processing of the Authz Request, including checking again for the expiry of request_uri. If the authentication process takes longer than 30 seconds, it fails…

[jgrandja]

@said026 Thanks for confirming. This was an oversight on my part so I'll label this as a bug. I'll get this fix in for the June 17 release. I'm thinking 5 mins should be sufficient to complete the authorization process (with user authentication). How does that sound?