Consider the following work flow.
I have a chat with, say, on a good day 10k people present.
We run something, that requires users to visit a website and login.
A normal user authentication flow, results in me being passed back a packet containing the access_token, refresh_token, scope, and expires time. BUT NOT THE USER ID
This means I can make requests to helix using an access_token and thus means I get 120 as my rate limit.
I then use the access token to a call to https://api.twitch.tv/helix/users with the header Authorization': 'Bearer SOMETOKEN' in order to recover the user’s ID. (only thing I need in this example)
Under this and dropping the link into chat,120 people logged in and I collect their user_id (only way to get their userID is to make a helix call), the 121st person (and beyond), resulted in a 429 (crashed my app as my non 200 code was derped but thats unrelated to this post).
So,
Under the current rate limit solution, I can only allow 120 people to login during one ratelimit time period.
Logically, I would expect ratelimiting to be done by ClientID/AuthToken Pair (maybe IP also) rather than ClientID/IP Pair? So I could do 120 requests for the authenticated user rather than 120 requests for my app? (Under this method you could also offer a lower rate limit to prevent abuse if done by ID/Token pair instead)
Yes I could ask for a higher rate limit, but I don’t think this is the answer for this example use case, as it will affect anyone and everyone whom is doing Login With Twitch?
Further more I can see it becoming a problem for larger bot users with one clientID and one IP trying to perform data lookups for 120+ channels.