Chat auth token annoying, constant refreshing

[tduva]

@Dist

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.

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.

@BarryCarlyon

The user client connects to my control server. and my control server deals with connecting to and maintaining the connection to Twitch.

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.

[Dist]

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.

[BarryCarlyon]

@Dist

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.

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

[Dist]

@BarryCarlyon

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:

The scope you are requesting is currently unavailable

You could try the new chat:read, chat:edit, and channel:moderate scopes since it looks like those don’t need to be whitelisted. They were recently introduced after chat_login started being abused but have not been added to the documentation yet.

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.

[tduva]

@Dist

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.

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

@Dist

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?

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.

[Dist]

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.

[tduva]

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.