responseTypeParameterMatcher should not be removed as it will break the Authorization Consent flow. Only remove openidScopeMatcher here as well as in OAuth2AuthorizationCodeRequestAuthenticationConverter

In OAuth2AuthorizationEndpointFilter, removing the openid scope and letting the response_type would result of a matcher like this:

(GET or (POST and response_type)) or (POST and !response_type)

which is the same as (GET or POST) that's why I removed the response_type matcher.

I can add it back if you prefer it that way.

I removed the openid scope matcher from the converter OAuth2AuthorizationCodeRequestAuthenticationConverter

would result of a matcher like this:
(GET or (POST and response_type)) or (POST and !response_type)

I believe we still need the response_type parameter in the matching because it's the difference between an Authorization Request or Authorization Consent Request.

However, I think we need to adjust the matching as follows:

Authorization Request
(GET or POST) and response_type

Authorization Consent Request
POST and !response_type

This should be applied to OAuth2AuthorizationEndpointFilter and both OAuth2AuthorizationCodeRequestAuthenticationConverter and OAuth2AuthorizationConsentAuthenticationConverter to be consistent.

Adding the response_type matcher to the GET request in OAuth2AuthorizationEndpointFilter will make the server return a 404 if a GET /authorize request is performed without the required response_type parameter, instead of a 400.

Specifically it is breaking the test OAuth2AuthorizationEndpointFilterTests.doFilterWhenAuthorizationRequestMissingResponseTypeThenInvalidRequestError() so I don't think adding this matcher in OAuth2AuthorizationEndpointFilter is a good solution.

For the same reason, adding these matcher rules to OAuth2AuthorizationCodeRequestAuthenticationConverter will make the request not enter the converter and prevent the server to return a 400 (it is breaking the same test).

This highlight the fact that a POST /authorize request without the response_type parameter will be treated as a consent request, so maybe we could add a condition in OAuth2AuthorizationConsentAuthenticationConverter to check if the user is authenticated?
A way to solve all this could be to create a new converter after OAuth2AuthorizationCodeRequestAuthenticationConverter and OAuth2AuthorizationConsentAuthenticationConverter to catch this missing parameter, so we can use the matcher in the converters?

Sorry, the matching rules stated in the previous comment need to be adjusted as follows:

Authorization Request
GET or (POST and response_type)

Authorization Consent Request
POST and !response_type

I tried this on my end and all tests pass.

I added a distinction between the Authorize matcher and the Consent matcher in OAuth2AuthorizationEndpointFilter.
A previous commit updated OAuth2AuthorizationCodeRequestAuthenticationConverter.
Nothing to do for OAuth2AuthorizationConsentAuthenticationConverter
It should be fine now

@sylvain-costanzo I will get to this next week. I'm trying to wrap up a priority task by end of this week.