Using client id to determine rate limits

Hi

When making anonymous requests to the helix API, the only way, as far as I can see, that the rate limit can be calculated is using the client ID, which we pass in through the header. My concern is that this client id can be easily stolen during the OAuth handshake. Furthermore, according to RFC6749, section 2.2, the client id should not be considered a secret.

The concern that I have it that once a particular client ID is obtained by a bad actor, they can perform a denial of service attack on our application by making frequent Twitch API calls, thereby exhausting the rate limit.

I have a few questions:

  • Are anonymous rate limits counted separately to authenticated rate limits? Or do they work in a similar way to the moderator/ non-moderator IRC limits?
  • Would you consider using a client-secret proof for anonymous requests instead of the client id alone? This can be an option that we turn on per app, so that when turned on, an anonymous request must provide the client-secret proof instead of the client id. There are probably many ways that this proof can be generated, and hashing the client-id and the client-secret (maybe with a nonce) is one way to generate such a proof.

Rate limit is by ClientID/IP Address pair

Kraken/Helix require ClientID there is no “anonymous”

1 Like

Rate limit is by ClientID/IP Address pair

Are you sure? This isn’t documented.

Kraken/Helix require ClientID there is no “anonymous”

What I mean by anonymous is that the client id is provided instead of a bearer token (i.e. we are not executing the API on behalf of a Twitch user). This should have been clear in the context.

Yes I’m sure. From testing and various conversations in various places

It wasn’t.

In order to use the TwitchAPI you MUST provide some form of identification

Being anonymous, ie providing nothing at all,

{“error”:“Bad Request”,“status”:400,“message”:“No client id specified”}

Providing a ClientID will identify you.

Apologies for misconstruing what you meant by anonymous.

1 Like

Thank you, Barry. I reckon this addresses the concern about denial of service, so thank you.

1 Like

When not sending a request on behalf of a user, app access token is the option.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.