In OAuth implementation, There are four kinds of TokenProviders. These are ResourceOwnerTokenProvider, ClientCredentialTokenProvider, AuthorizationCodeTokenProvider and RefreshTokenProvider. It's the TokenProvider that implements the checks for valid user Id and valid client Id. Therefore, the TokenProvider should also implement the check to see that the token is mapped to the same user Id and ClientId as expected. The access    token need not be stripped by the proxy. If the proxy strips the access token and forwards it on to the API implementation, then it should implement the check to see that the token maps to the user and the client correctly. Unless the access token is received by the API implementation, it is hard for the API to validate the same. The only mitigation in such a case is to keep a registry of all TokenProvider calls such that the incoming clientIds are recorded and queried against the proxy. If a client registry fails the proxy lookup, then it should be denied any tokens. For clients that are registered but not user authorized, we look it up with another call to the proxy asking for the applications allowed by the client. If two clients are registered and authorized by the same user, the registry for clientId and accessToken maintained by the API will mitigate the hijacking of token between these two clients. This step by step check is only necessary when we are relying on a proxy that doesn't automatically validate the clients before issuing the tokens to them. These steps rely on the assumption that the proxy provides methods for lookup a client information based on the client Id and to list all the clients authorized by a given user.

When the API has its own implementation of an OAuthProvider, instead of relying on the proxy, then the token database maintained by the API will have an association between the token, the user and the client. That enables a single central checkto validate a given access token instead of authenticating a client.
OAuth RFC mentions there are more than one way to authenticate a client and the common practice being the use of a client credential such as a client id and a client secret. The other kinds of client authentication can be password or public/private 

key pair. The only thing the RFC mentions as a must is that the clients should not be authenticated by their apikey or clientid alone since it is public and can be switched. Therefore a lookup of the client secret against a client registry is required. This client secret is sent to the authorization server in the request body as opposed to the apikey that's passed as 

query string. Further, the RFC distinguishes the clients as confidential clients and public clients saying the confidential clients should have a client authentication method.