In OAuth, 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.