Instagram

* It uses the Access Token as identifier;

* It uses a hourly based rate limit;
* Rate limits are defined per endpoint AND a global one;
* It returns status 429 (standard) when its limit is exceeded.
* It keeps it blocked UNTIL the rate be bellow in the last 1 hour period.

Facebook

* It uses a token+IP as identifier (Ref.: https://goo.gl/Pw4wqf );

* It uses a hourly based rate limit;
* It returns status 4 (non-standard).
* It returns HTTP Headers about the remaining limits.

Twitter

* It uses a 15 minutes window;

* It returns in the HTTP header infos, like the limit for the endpoint,
and number of requests left in the 15m window.

How to ensure that only the desired App could use an Access Token?

As Ugolini suggested, there is at least one way to protect against the use of
stolen tokens.
To do that, we need to Sign the request, it is a pattern from OAuth and twitter
has some examples.

It uses aditional informations in order to create the signature,

like the use a Consumer Key (our Client Secret?), a timestamp, the token itself
and so on.

Related Material:
https://dev.twitter.com/oauth/overview/authorizing-requests
https://dev.twitter.com/oauth/overview/creating-signatures
https://oauth1.wp-api.org/docs/basics/Signing.html

My Considerations:

Both Instagram & Facebook uses 1 hour periods, I think it doesn't fit for us,
because
they can handle and wait for longer times without affect the system, we don't.
We need to detect the attacker faster, otherwise we might face one hour of lag
prior
to stop it, maybe 1 or 5 minutes periods.

Maybe we can create a custom Filter (extending throttling.BaseThrottle) that

consider
the Access Token (as it works for Users and Scopes) as identifier. By doing
that. we won't
have problems with the correctness of IPs (Due to proxies & VPN/Tor the
attacker might use).
It will also be easy to handle distributed attacks since multiples IPs will be
grouped
(since it uses the same Access Token or Access Tokens that belongs to the same
Organization).