I have heard that CSRF prevention techniques are not natural for Web APIs.
For instance, we might have a client application at domainA that implements both the Synchronization Token Pattern and the Cookie-to-Header pattern. When the client POSTs to the resource server at domainB, the resource server needs to validate those security values, and since the resource server would not know what synchronization token value nor what cookie-to-header value to expect, it will have a hard time validating those.
That being said, the resource server could validate the synchronization token and/or the cookie-to-header value using the same technique that it uses to validate the access token. Given that, why are those two techniques considered inappropriate for a Web API?