The twitch integration in my game is working. The game connects directly to twitch, there are no other servers involved.
However, I’m unsure how to store the token, so it can be used the next session. Ideally I’d like if nobody unauthorized can get their hands on it, even if the PC itself is compromised.
If you’ve made a game with twitch integration, how did you deal with this?
Without a secure way of storing the token (or alternatively, forcing it to auto-expire the same day), I’m not going to dare make the game ask for any permissions further than just reading chat.
Update: It was suggested to me I implement support for Windows Credential Manager and Apple Keychain into my game. That’s probs the way to do it.
I would use Device Code flow Getting OAuth Access Tokens | Twitch Developers
Then store as is recommended for the OS’es and/or wahtever the game engine supports.
But since it’s the users own token it might be overkill to og well overkill with it.
But this might depend on what permissions you are getting from the user. If it’s read only then you are good since it’s LITERALLY just read only. And theres minimal damage from it leaking. And again it’s the users own token.
So it’s more matter of what the game engine supports for storing, as the game engine might already have advice on what to do thats specfic to the game engine.
Altneraively don’t store and prompt each boot up. (Using DCF if the game isn’t launcher in 30 days the refresh token dies anyway)
TLDR: the Game Engine should have advice/plugins here rather than “Twitch specific” advice on this one.
One more option if the game also talks to your own backend: keep only a short-lived access token in memory and store the refresh token in the OS keychain/credential store as suggested above. That way a copied config file or save folder never contains anything usable. If you only request read-only chat scopes, the risk from a leaked token is small, and users can always revoke it from their Twitch connections settings.
For Ref: DCF tokens are only valid for 4 hours. And the refresh token 30 days (and single use). So those are “short lived” by design.
I’m not depending on any game engine or plugin features for storing things, so my capabilities only depend on whatever I can do in C#, which is quite a lot. Windows Credentials Manager and Apple Keychain should be doable (I’m a bit more scared of how to do it in Linux though)
Depending on whether the player has enabled “auto pin learned commands to chat” I may need to ask for just basic read chat, or also permission to post messages - meaning security is critical in this mode (I will not implement it at all if I can not guarantee safety)
The easiest solution would definitely be, as you suggest, to not store the refresh token at all, except in memory while the game is running. Maybe I’ll go for that!
I mean it’s the user own token stored on the uses own computer.
And the transaction is localised to that single computer.
So if someone has broken into the computer they are gonna session steal everything. So a token with limited capabilities is tiny to everything else, if the users computer is comprimised they will take the first party Twitch session, instead of your limited key. for example.
So it’s less of a concern storing the users own token (or refresh token) to their own computer. So yes use credential storage to secure it. But just note it’s fine to hold on to the users own token inside the game. And avoids the annoyance of the browser popup at game restart (for whatever reason)
For pinned chat, since you have to ask for “access to all channels a mod is of” it’s a bit more concern but again it’s the users own token on the users own computer, it’s not more dangerous that say if the user users chatty or streamerbot…
Scopes for this minimum is
- user:write:chat
- moderator:manage:chat_messages
as Reference | Twitch Developers can let you send and pin in the same operation. But the pin is default 20 minutes so you might need to also call Reference | Twitch Developers to update to whatever time length you need (within the limits)
No read chat needed here for the described use case.
Oh yeah, this indeed only becomes relevant if someone breaks into their computer and get access to the files. But still, since it’d allow someone unauthorized to post in chat, I want to do everything right by the book, even if this is a scenario that never ended up occurring in real life.
Maybe it doesn’t hurt that I learn how to implement support for credentials managers anyway 