The removal of the oidc scope matcher now allow OAuth2AuthorizationEndpointFilter to send POST /authorize request without the openid scope to the converters.

But I see two issues with this development:

1- The default converter OAuth2AuthorizationCodeRequestAuthenticationConverter still need the oidc scope to be used, but removing this condition will mess things up with the consent request, who, in the default implementation and in the demo-authorizationserver sample, is also a POST without the openid scope (and without the response_type parameter, who make this converter throw an error).

Tackling this issue seems a bit out of scope for this PR so I didn't touch anything, and it can be surely be solved with some custom converters.

2- Another minor issue I see is that the oauth2 specification is saying that a /authorize request (GET or POST) is supposed to have the parameters in the query string,

The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI using the "application/x-www-form-urlencoded" format

contradicting the OIDC spec saying that POST requests must use the body

If using the HTTP POST method, the request parameters are serialized using Form Serialization, per Section 13.2.

So this way of getting the request parameters may have to be updated, but again it can be solved with a custom converter, so it also felt out of scope of this PR.

Considering these 2 issues, I am not sure the PR is answering the "Support POST for authorization code request flow", and I would like your opinion on this

Rewording my thoughts, I don't think these issues are completely out of scope, but they need significant refactor with more regression risks than the small change here.
The original goal of gh-1811 was to allow a POST /authorize without scope parameter to be sent to the converters, and this PR allows it.