Chat auth token annoying, constant refreshing

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.

1 Like

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:

    ?client_id=<your client ID>
    &redirect_uri=<your registered redirect URI>
    &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

With the Implicit Auth Flow it can’t be done without opening a website in the browser, so it’s always intrusive (it requires a local webserver to retrieve the token). With the Auth Code Flow it requires a client secret, so at least part of it has to be done on a server, not the client.

Currently the app runs on the users computer, open the Twitch Auth Page for the user, gets redirected to localhost, grabs the token and stores it locally.

I don’t like the idea of all my users access token having to go through my server, it just adds another possible security vulnerability. Currently each client only communicates with Twitch to get a token and the token is then stored locally, so the only way for a token to be leaked would be if the users computer is compromised or the user shows it on stream or something. But if all the tokens have to go through my server then if my server is compromised or the tokens would accidentally be logged somewhere (even if I don’t store them on purpose), then a whole lot of login data would be leaked all at once. Depending on whether the client secret is leaked as well (and when the leak is noticed) they could be used for a while.

But let’s just assume that the server is secure. How would the client even get it’s token through it? Obviously I can’t just have the client send the Refresh Token + Old Token and receive a New Token from the server, because then everyone could essentially use my client secret to request new tokens. So the server needs to somehow know which clients are allowed to request a token for which refresh token. I could make the client store some kind of token so it can identify itself to the server, but that would have to be stored locally on the users computer alongside the refresh token and access token, so if the refresh token and access token would be leaked somehow, my server’s token would probably be as well, allowing whoever would maliciously want to use it to request new tokens through my server.

I just don’t see how it really adds a lot of security. It doesn’t fully solve the problem of the token being leaked (only if somehow really only the token would be leaked), but it adds complexity and adds new possible security issues. It makes sense if it’s a kind of application that needs the access token on a server anyway, then you just have to accept that. But for a purely clientside application I’d rather not have my tokens go through a third-party server, if I can help it at all.

If some apps could have a longer expiration time (maybe having to apply for it), then going through the Implicit Auth Flow e.g. once a month wouldn’t be too bad, but it would still prevent tokens that have been leaked and forgotten years ago to still be valid.

Fast expiring tokens make a lot of sense in the context of any apps that live in the web, since especially in that case it’s possible to leak a lot of them quickly if there is some kind of vulnerability on the website or server. But for a clientside app where everything is happening locally, it would mostly just be single tokens being leaked through the users own doing, like loosing an USB stick with a backup on it or their computer being compromised.

It feels like you’re over-complicating matters. If you want to do EVERYTHING client-side, then your clients could register their own app, go through the auth code flow on localhost (only needs to be done 1 time), then from then the entire refresh process is automated, still client side, and still no more webserver as that’s not needed to refresh.

If you don’t want to do everything client-side, and you want to have a single app registered which is on your end, then why can’t your clients go through the auth process on your server, and any time it needs refreshing they connect to you and your serer handles the refreshing and returns a new token?

From the sounds if it, you seem stuck into one way of going about it, and I don’t blame you, not many people like change, but it’s not like there isn’t a way for you to adapt, there are options, several in fact.

And sadly, you need to email twitch if you want to use chat_login on new apps. So………

True, but then I saw this this post in another thread that indicates there may be new scopes coming for chat that don’t have the same requirements to email Twitch to allow their use:

But yeah, there are pros/cons to different implementations. Some will require the dev to change the way they do things.

It sort of reminds me of when Twitch started making ID’s as important as they were. Most devs saw it as an indication of the (then not announced) username changes and made changes they needed, where as others who didn’t like changing from using usernames as reliable key kicked up a fuss.

Yeah, I’m sure thousands of people having to register their own app makes sense.

And you’re missing the main point here, which is in what way is it more secure to change the whole auth process to go through a third-party server (which would be much more at risk of leaking a large amount of login data, if it were to happen at all), when the only way for a token to realistically be leaked would at the same time also leak all the other credentials needed to refresh the tokens through the third-party server, since they would all be stored locally in the same place anyway. It’s not about being lazy or not wanting to change, I’m all for making things better and more secure (hence me considering all the options and writing long posts about my thoughts on it). I simply don’t see how it does make it more secure for an app of this kind, except for the very rare occurence of accidentally showing your token on stream or if an attacker that has access to that leaked data is too lazy to figure out how to make a request to the third-party server.

If you follow common security steps then there’s no reason to assume doing the refresh step through a server rather than client side would be insecure (and the number of server-side apps on Twitch that have never had security issues, and all do refreshing server-side, should be evident that it’s not something to be afraid of).

While I’m sure witch have data on the security side of this, it’s not the sort of thing they disclose as it’s one of those things they keep quiet on for obvious reasons. So we may never get to see the exact reasoning and stats for why refresh tokens were implemented, but at least they have given us more than enough warning and have been telling us for ages that refresh tokens are going to happen.

So what steps are common to identify which clients are allowed to refresh a token through my server? That’s the main issue that I’m having with this.

And I’m not afraid of it, I’m just thinking it’s a new risk (however small it is) that is unnecessary for clientside apps, when at the same time it doesn’t improve security (as long as I can’t properly determine which clients are allowed to refresh a token).

It’s quite obvious that expiring tokens makes sense. It’s ridiculous that tokens last for years. It’s just a huge step from “tokens last literally forever” to “tokens last half a day”. And using a client secret and refresh token makes sense as well, for serverside applications. And reauthorizing silently through the implicit flow in webapps make sense as well. It’s just that one kind of application where I don’t see how it makes sense. I mean I’d rather have my users not notice refreshing tokens at all, instead of using the Implicit Flow once a month (theoretically, if Twitch would allow longer lasting tokens), so it’d be better to just throw together some serverside code and be done with it. But I’d rather actually think this through and understand how I can make it as secure as possible.

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