feat(auth): add support for device code grant flow#5680
feat(auth): add support for device code grant flow#5680Nerixyz wants to merge 28 commits intoChatterino:masterfrom
Conversation
|
Been running this for a few days and seems solid 👍 |
|
Should we validate that stored tokens have all of |
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. |
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.
|
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.
|
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](https://gist.github.com/iProdigy/a724f5eaf0d0cbff4e8dc2fd79424ea4) wouldn't work if we switched auth to DCF (unless we forced streamers to continue authing from the website)
|
|
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 (this can be done in a separate pr) |
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
publicclient type, the client-id is limited to DCF-only (as far as I understand).(effectively) closes #5169.
Here's a cool video I took in February when I started this (hasn't changed much):
firefox_2024-02-11_12-24-45.mp4