Explore moving Bearer Token authentication before Csrf in the filter chain

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.

Start by reading the filter-order behavior around BearerTokenAuthenticationFilter, CsrfFilter, and OAuth2ResourceServerConfigurer, then review issue #8668 for related CSRF and Resource Server context. Trace the impacts of moving bearer processing earlier, including the proposed authority and configuration approaches. Done means the impacts and a viable direction are documented; the ticket is not yet ready for implementation.