Chatterino
feat(auth): add support for device code grant flow
This PR adds support for Twitch's Device code grant flow (DCF). This makes it possible to (effectively) use tokens for much longer without requiring the user to reauthenticate (assuming the scopes didn't change).
Currently, this uses a client-id I created (THIS MUST BE CHANGED BEFORE A MERGE). Because we use the public client type, the client-id is limited to DCF-only (as far as I understand).
(effectively) closes https://github.com/Chatterino/chatterino2/discussions/5169.
Here's a cool video I took in February when I started this (hasn't changed much):
https://github.com/Chatterino/chatterino2/assets/19953266/259ba236-3f02-4375-9ef9-c5cc455ebdd9
Should we validate that stored tokens have all of DEVICE_AUTH_SCOPES? (or perhaps should be tackled in a separate PR)
Should we validate that stored tokens have all of
DEVICE_AUTH_SCOPES? (or perhaps should be tackled in a separate PR)
Twitch does that when we refresh tokens (the last time I tested it). The error you get there is pretty bad, though (iirc, it's the same one you get when the token is invalid). Should be enough to add a message with a link to re-authenticate.
Should we validate that stored tokens have all of
DEVICE_AUTH_SCOPES? (or perhaps should be tackled in a separate PR)
I've done that now.
Will this not be broken when we NEED to use eventsub? Then we will not be able to access public data about people who log in to Chatterino.
Then we will not be able to access public data about people who log in to Chatterino.
Only if we use an app access token. We don't use an app access token on the client.
We will be no doubt forced to switch to EventSub sooner or later. As I understand it the problem is that we cannot give each client a direct connection to Twitch EventSub due to limits on conduits and their rate limits and thus we must build our own pubsub.
@pajlada probably knows more about this
W dniu 1.02.2025 o 19:30, nerix pisze:
Then we will not be able to access public data about people who log in to Chatterino.
Only if we use an app access token. We don't use an app access token on the client.
As I understand it the problem is that we cannot give each client a direct connection to Twitch EventSub due to limits on conduits and their rate limits and thus we must build our own pubsub.
We connect to eventsub locally via websockets.
DCF works for normal eventsub websocket (but we won't be able to get redemptions events if not the broadcaster)
we will never use app token client-side (would require each user to create a dev app to obtain a client secret)
but yes my server-side conduit RFC wouldn't work if we switched auth to DCF (unless we forced streamers to continue authing from the website)
I would like this idea and PR to be held until we decide to either accept or reject the ideas proposed by @iProdigy in the RFC. There is no way we can force streamers to auth in the website while allowing others to use the new flow, so we are forced to pick which one we want more.
W dniu 1.02.2025 o 19:51, iProdigy pisze:
but yes my server-side conduit RFC wouldn't work if we switched auth to DCF (unless we forced streamers to continue authing from the website)
https://www.twitch.tv/pajlada/clip/BoldBoxyMagpieSmoocherZ-NwusH1Za45BgtGXt
It is a sad reason. Yet I don't think we have any sane option that keeps both the RFC and device auth unless eventsub things suddenly change (which I doubt). The only (insane) option I could think about is logging in users twice once with the API server and once with device auth for the client. Having users pick between two types of login to choose from WILL result in a disaster of epic proportions.
W dniu 16.03.2025 o 11:52, Wissididom pisze:
Wissididom left a comment (Chatterino/chatterino2#5680)
https://www.twitch.tv/pajlada/clip/BoldBoxyMagpieSmoocherZ-NwusH1Za45BgtGXt
if we want to pursue the RFC, at the end of the device flow, we can display a message asking streamers to also auth with the website (hyperlinked) - but we can have a separate page that just says Success; you may now close this tab on redirect instead of yielding a copy-able access token to avoid confusion
(this can be done in a separate pr)