Concerns about storing bearer tokens

[gamesaucer]

I am working on a desktop app (i.e. it has no online component), which means I’d be locally storing the client-id and the bearer token for any users the app is authorised to act on behalf of (after obtaining the latter using implicit code flow).

My concern with this is that someone with ill intentions could take these two codes and use them to spam or otherwise misuse the API. This would look like it’s my app doing it, even though it’s not. I have two questions regarding this potential issue:

1. Is the rate limit bound to bearer tokens when provided (or something similar), or is it global? If it’s global, it would mean that misuse could result in a DOS attack on my app.

2. In case someone does abuse the API in this manner, will I, as the app author, be held responsible (i.e. responsibility based on client-id) or will the user making the abusive requests be held responsible (i.e. responsibility based on bearer token). I do not want my app to be banned because of one bad actor getting hold of a bearer token.

It’s also possible that someone could use a client-id to make requests without the use of a bearer token, and I was also wondering how exposing the client-id might potentially open that up as an attack vector for bad actors.

[Dist]

@gamesaucer

Is the rate limit bound to bearer tokens when provided (or something similar), or is it global? If it’s global, it would mean that misuse could result in a DOS attack on my app.

The rate limit is per user so requests from that User Access Token wont impact the rate limit of your other users. If the user opens up multiple instances of your app though they’ll potentially be using up their own rate limit faster.

@gamesaucer

In case someone does abuse the API in this manner, will I, as the app author, be held responsible (i.e. responsibility based on client-id) or will the user making the abusive requests be held responsible (i.e. responsibility based on bearer token). I do not want my app to be banned because of one bad actor getting hold of a bearer token.

The Twitch Developer Agreement states:

IV. Developer Accounts and Rate Limits

…
B. Keys. Once you have successfully registered Your Services, you will be issued one or more unique security keys, secrets, tokens, access codes, passwords, or other credentials (collectively, “Keys”). The Keys enable us to associate the Program Materials with Your Services and end users of Twitch Services. All activities that occur using your Keys are your responsibility. Keep them secret. Also, you may not sell, transfer, or sub-license them.

So you are responsible for the keys, but if you take reasonable precautions to prevent misuse (such as not making displaying them to the user, or making them available outside of your app), and your app isn’t designed with malicious intent, then it is unlikely Twitch would take action against you (please keep in mind I’m not a legal expert, nor do I speak for Twitch).

OAuth Tokens being used client-side always have an inherent risk, but that’s partly why they do expire, and individual tokens can be revoked if needed, and this is something that all apps that do client-side requests have to deal with, not just Twitch apps but other services that use OAuth Implicit Tokens too.

@gamesaucer

It’s also possible that someone could use a client-id to make requests without the use of a bearer token, and I was also wondering how exposing the client-id might potentially open that up as an attack vector for bad actors.

Client ID is public, as any user going through an OAuth flow, regardless of the type, or if it’s on a website or in an app, can see the apps Client ID in the URL. It’s impossible to get User Access Tokens without exposing it. It’s not something you need to be concerned about.

[gamesaucer]

Thank you, that’s very helpful.

@Dist

So you are responsible for the keys, but if you take reasonable precautions to prevent misuse (such as not making displaying them to the user, or making them available outside of your app), and your app isn’t designed with malicious intent, then it is unlikely Twitch would take action against you (please keep in mind I’m not a legal expert, nor do I speak for Twitch).

It seems to me that the keys they’re talking about are specifically secret keys, as they’re issued upon completing registration and are supposed to be kept secret. So I’m not sure whether that would apply to a bearer token issued on behalf of a user. The phrasing of that section seems a little ambiguous in that regard.

[Dist]

The list of of “keys” does include access codes, passwords, or other credentials which would be representative of OAuth tokens.

The phrasing can be a little hard to parse as it is it is a legal document, so if you’re unsure about anything you should consult a expert as none of us here on the forums can give definitive legal advice on how to interpret it.