userApprovalHandler: if you only have one client in your system, I agree the users should not have to approve it accessing their data.
oauthAuthenticationEntryPoint: Normally, if authentication fails, the response type is JSON. Documentation says “If authentication fails and the caller has asked for a specific content type response, this entry point can send one, along with a standard 401 status.”
clientCredentialsTokenEndpointFilter: Issuing an access token is a two-step process. First, you send the user to the resource server to authenticate. This redirect is authenticated by the client, ideally with the HTTP Headers (key + secret). In return, the client gets a code, which can be exchanged for a token.
You do not directly trade the key+secret for a token, as it contains no approval from the user.
resourceServerFilter: I think the purpose of this is indicating what clients have access to what resources, if you have many different resources.
accessDecisionManager: For OAuth2 you need a ScopeVoter, so the default Manager is not good enough.
Generally:
If you will only have one client accessing the resources on behalf of the users, then maybe consider using Digest instead of OAuth2?
And if you only want to authenticate the client (not the user), then OAuth2 is overkill. Client authentication in OAuth2 is really same as Basic Authentication over https.