Consider aligning OAuth 2.0 Access Token Response parsing in BodyExtractor

For reactive applications, the default implementation of BodyExtractor<Mono<OAuth2AccessTokenResponse>, ReactiveHttpInputMessage> used by AbstractWebClientReactiveOAuth2AccessTokenResponseClient is OAuth2BodyExtractors.oauth2AccessTokenResponse(). It uses Nimbus to parse an OAuth 2.0 Access Token Response.

The Nimbus implementation determines if the response is success or failure based solely on parameters in the response. By contrast, for servlet applications, a RestTemplate or RestClient uses an error handler that is invoked based on the HTTP status code of the response. This means that handling of an OAuth 2.0 Error Response in particular is not aligned between the two stacks. It would be nice if we could align error handling. Further, on the reactive side, parsing is tied into error handling and applications that wish to customize one must customize both in an inconsistent way.

We could also consider re-using the parsing logic from the servlet stack in the BodyExtractor for reactive:

• DefaultMapOAuth2AccessTokenResponseConverter can be re-used for converting response parameters to an OAuth2AccessTokenResponse
• OAuth2ErrorConverter (currently a private inner class of OAuth2ErrorHttpMessageConverter) can be re-used for converting error parameters to an OAuth2Error

Start with AbstractWebClientReactiveOAuth2AccessTokenResponseClient and OAuth2BodyExtractors.oauth2AccessTokenResponse(), then compare their Nimbus parsing with DefaultMapOAuth2AccessTokenResponseConverter and OAuth2ErrorConverter from the servlet stack. Review OAuth2ErrorHttpMessageConverter as the current location of the error converter. Done should align reactive and servlet OAuth 2.0 error handling while allowing parsing and error handling to be customized independently.