I am working on an extension which will integrate twitch and a single player game.
I have made a static html + css + js extension where the extension uses a websocket with a very specific message structure to communicate with the EBS hosted on heroku.
Everything works fine extension wise but I am not sure how should I handle the authentication.
I have the onAuthorized callback which sends a message to the ebs with the current jwt.
The ebs validates if the jwt is correct and if it is it assigns a GUID style token to the user and sends it back to the extension.
After that the extension gets activated and every message sent from it has the ebs token assigned to it so the ebs can validate the the token against the one stored in the database for a specific user.
Is there a better way to achieve this without spamming the twitch validation service ?
Also is there a simple way to request a new jwt from twitch with a direct callback ?
Everything works via websocket so I would like to avoid having another way of communication in the extension.
Also one more question. Do I even need the jwt in that situation when I’m using websockets for communication and my own way of authentication between the extension and the ebs ? In this case the use of jwts seems a bit redundant to me.
I am trying to make the communication secure but I see no other point in using the twitch jwt other than validating the initial connection and recognizing the user.
I don’t know though what the twitch’s stance on that is.
So twitch is not enforcing the use of jwts ? It’s fully up to the dev to make their own extension secure ?
I would like to avoid a situation where I will build the entire system and then twitch would complain about me not using their validation method or something.
I don’t think you have read the docs and don’t understand what the JWT is for.
An extension loads
An extension calls onAuthorised with a JWT.
You can parse (without validation) that JWT extension side to look for the “real” TwitchID, if your extension asks users to share their TwitchID. If your extension doesn’t ask a user to share their ID then you’ll only have the opaqueID.
You can send that JWT to your EBS, in order to test that JWT for it being valid or not against your Secret and then parse our the data, again, for the opaqueID and/or the realTwitchID.
You could pass that JWT via the websocket auth as you describe, but it depends if you need to pass the JWT out if you need the TwitchID of the user or not.
Basically JWT’s safely inject the TwitchID into an extension from Twitch itself.
Twitch Extension into EBS, you can do whatever you want to secure that connection depending on the needs and work flow of your extension.
I run four twitch extensions at time of writing, the three panel extensions all (in this case HTTP POST) the JWT offsite to fetch and return user information from my EBS, (ChannelCurrency, Giveaway status etc).
TLDR:
the JWT is just a verifiable string that contains the TwitchID of the user (if you have enabled TwitchID sharing in your extension and the user has shared their TwitchID).
If you want to use the JWT as part of your websocket handshake sure, do you need or are required to no.
I get the JWT from the onAuthorized callback when the extension loads and then I’m sending it to the EBS.
The EBS then checks if the JWT is valid and assigns the user a unique token which then it sends back and which has to be present in every message from the extension to the EBS afterwards.
The tokens assigned by my EBS are valid for 30 minutes.
After the token expires the EBS asks the extension for a new JWT.
If it’s delivered the cycle repeats, if not then the communication ends.
My main concern is if twitch will complain about a solution like that ? I’m especially not sure since I’m using a websocket and most people seem to be using http.
You cannot make the extension front end generate a new JWT on the fly. If you do this, the Extension will just send back the same JWT it sent 30 minutes ago.
People avoid WebSocket’s as scaling WebSockets is “difficult” (and can be expensive) in comparison to Scaling HTTP, if a large streamer suddenly and without warning starts using your extension (and it falls over), then it’s all broke.
What about the twitch api v5 methods for getting and refreshing a token ? By new I don’t mean completely new unique JWT, it can still be the same, I need it only to confirm that it’s still valid.
As for using a websocket I am using a lot of bit shifting to compact the data as much as possible.
Wouldn’t that be more efficient than using http ?
In that case I guess I will have to tweak the system to wait for the JWTs which arrive by themselves periodically
So http is superior to websocket in this manner ? I was also thinking about a scenario where a big streamer starts to use the extension and I’m worried that websocket might not hold up.
My message format has a proper header lengths and everything else so the framing is easy to decode so there is nothing to worry about there. I’m worried if the npm ws will hold up when for example 1000 people will start using the extension.
I want to avoid page loads in my extension which has many different tabs and sub tabs therefore I did a static html + js which talks to the EBS via websocket since I want to send data to the EBS and pass it over to a custom app which sits on streamer’s pc and also receive a response from the EBS to the extension which might affect many different parts of the extension (even those which are not currently visible) (I want the extension to load only once at the beginning since it’s mostly built out of images)
I haven’t done it with http yet but I know that people tend to send a render of the extension back to the extension instead of creating a static html ? But I guess that would also result in the images reloading with every tab change.
