So with the new token refresh system you have to keep refreshing your auth token every 12(?) hours.
At the moment you can use old app client-ids to get a token that doesn’t need to be refreshed, but in the future that will no longer be an option according to the docs.
What is the workaround for people who like to use an IRC client like e.g. mIRC? Besides going off to manually fetch a new token, replacing the old one with it, and then re-connecting. Every. 12. Hours.
Would love to know.
Also interested in this. It doesn’t seem to factor in any IRC client users.
I heard but don’t recall where that you’ll only need to refresh before connect. And don’t need to refresh every 12 hours. When it expires it doesn’t also break your chat connection
Are you suggesting people should keep their computers on all night just so that they don’t have to refresh the token the next day? 
No what I’m saying is that you only need to use the refresh token when connecting to twitch chat. which will also do the “is the app still connected” check.
I’m the context of a chatbot or chatty you basically follow what mixers api does for the same. At boot use the refresh token to get a new token. Then connect to chat. (Or not if the refresh failed)
I have no advice or guidance about what a user should or should not do.
That’s the whole point I’m making in the OP. You have to do that refresh manually every 12 hours in a chat client that isn’t specifically made for Twitch and made to use the new refresh token system. E.g. mIRC.
I know now about what mIRC scripting can or cannot do. Sure it does sound like we are moving away from “easy” compatibility with “standard” IRC clients. So I dunno
It doesn’t even have to be an in-app script that does the refresh process, the users of external chat clients can just create a little app (or find one online, as I know a lot of external chat users are not technically minded) that does refresh process, edits the config for the new token, then launches the chat app.
It’ll add a minor delay to the launch time of the app, but it’ll be automated at least. It’s either that or use a BNC which can handle all that, and just have users connect via that (if connecting via a proxy is within Twitch’s ToS, I haven’t looked if that’s something they may have issue with).
All this sure sounds like a whole lot of work just to connect to IRC. And also entirely relying on other people to make these tools for Twitch and your specific client.
I would love to hear from someone at Twitch if this is an intended consequence of this new refresh system, because I don’t see any benefit in it - not even for security since the client has and uses both the access and refresh token.
In my opinion there should be an auth flow where you get a non-expiring token to use for cases like this, where the access and refresh tokens are stored and used by the same and only client.
From a security standpoint this helps with the issue of leaked tokens. Over the last few years I’ve seen dozens of tokens leaked, either maliciously or by mistake (paste the wrong token on forums, or forgetting to remove it from github (and then forgetting github has a history)) and then never revoking the tokens. Of those, I know at least 20+ that are still valid and have the chat login scope (some are scoped for everything!), so I, or anyone else, could log into chat as them right now.
By requiring refreshing of tokens, it will dramatically cut that vector of attack. It wont stop all types of attack, such as phishing where the malicious entity poses as Moobot/Nightbot and can just refresh the tokens themselves, but for leaked tokens this’ll put at stop to that (at least it will when older generated tokens are forced to expire at some point in the future).
I assume you’re talking about tokens visible on screen. Because for anything else, like for the client having both the refresh and access token, the refresh token would be leaked as well.
It seems strange to me that leaking data on screen would be the entire reasoning behind putting these restrictions on everything. Or the very least not opening the restrictions to certain use cases, e.g. through a different auth flow.
There are many situations in which an access token would be leaked without a refresh token. Even if a refresh token is leaked it’s useless to a malicious user without also having the client secret associated with the app that created that token in the first place. The number of leaked (and still valid) access tokens is a security risk, from my experience the number of leaked refresh tokens along with client secret is very minimal, but I’m sure Twitch have more data on the security implications (either way, minimising a known area of attack is a good move, and indefinite tokens seemed more out of laziness on the part of devs rather than a sufficient need)
It makes sense for many apps, but my problem is how would a purely clientside non-web IRC client handle refreshing a token? Since the client secret needs to stay secret it can’t be shipped in the program, since it would only be obscured at most. Going through the whole authorization process every 12 hours isn’t feasible either for a non-web client where it is pretty intrusive. Is every user supposed to register their own application so they each have their own client secret? Am I missing something?
I think expiring tokens makes a lot of sense, it would prevent leaked tokens that are years old to still be valid. But for some apps a more reasonable timeframe is necessary. Going through the authorization process e.g. every month wouldn’t impact users too much but would still reduce some of the risk.
Implicit auth. And when the token expires, go thru the oAuth loop.
Implicit goes:
GET https://id.twitch.tv/oauth2/authorize
?client_id=<your client ID>
&redirect_uri=<your registered redirect URI>
&response_type=<type>
&scope=<space-separated list of scopes>
So no “Secret” just a ClientID
Both agree and disagree, if you do it with force_verify off, most users won’t notice the oAuth jump.
I am using the Implicit Auth Flow. On a website you may indeed not even notice the process, but I was talking about non-web clients. So that involves leaving the application to a browser (if I don’t want to just randomly open a browser I have to ask them first), maybe they have to log into Twitch, maybe something goes wrong with retrieving the token (like the user not having JavaScript enabled on localhost, or the local webserver not being able to listen to the port).
That’s all fine if you don’t have to do it literally every day. Or several times a day. It’s not just about logging into chat either, it’s also about API requests, so even if you can stay connected through the token expiring you will still have to request a new one every 12 hours. It’s very intrusive. What if a streamer has to do it mid-stream? What if he’s a speedrunner who can’t just pause the game? If it were something like a week or a month I could warn the user ahead of time to refresh it. Again, for desktop clients that don’t already live in a browser anyway.
How do you have your app set up? Refreshing tokens doesn’t require running a webserver, and it can be automated without the need for user interaction. So to answer your question, what if a token expires mid stream? Well then a properly designed app would renew it (preferably before it actually expires) and the entire process would be transparent to the user and without any issues.
I would follow a similar structure to the extensions model.
The user client connects to my control server. and my control server deals with connecting to and maintaining the connection to Twitch.
Seems like way overkill for a simple IRC client.
If you want something for a “simple IRC client”, users can just have a simple app that gets run before irssi/mIRC/xchat/whatever, checks if the token is expired, if it is refresh it and save to the appropriate clients config file, launch that client and terminate the app. Would add a minimal amount of delay, and only happen when launched.
Some IRC clients could even do this internally with scripts and not need any extra app.
Is there some annoyance with token expiration? Sure. But it reduces a security issue and once you automate token refreshing it’s not a big deal as the overhead to maintain a valid token is minimal. Plus this is already a very niche subset of Twitch users that this will be an issue for.
Agreed. I wandered into “not just irc client” territory