NOTE: This is a ticket that the Spring Security team is reviewing for inclusion. It's not considered ready to implement yet. When it is, this disclaimer will be removed and the title may change
It appears that the processing of the bearer token itself can be done safely regardless of the HTTP Method type. Having the filter in advance of the CsrfFilter would allow taking into consideration, via configuration for example, whether or not it should require a token on a given Bearer request.
For example, BearerTokenAuthenticationFilter issues a FACTOR_BEARER authority. CsrfFilter would potentially read this and decide that when this factor is present, CSRF is not required.
Or, BearerTokenAuthenticationFilter itself could possibly be configured to not skip CSRF.
Either could allow OAuth2ResourceServerConfigurer to leave CsrfConfigurer as-is and allow applications to change CSRF behavior by way of its request matcher.
Note that https://github.com/spring-projects/spring-security/issues/8668 is discussing ways to address activating CSRF and Resource Server together. This ticket is primarily about exploring the impacts of changing the filter order.