Twitch extension > EBS authentication via websocket


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.


JWT’s are validated using your Secret, there is no service to call…

By this I meant validating the jwt from the extension level so I wouldn’t have to store the secret in the extension itself.

the JWT should be sent off site into your EBS to be validated.

You can’t do it locally in the extension

No. But Twitch extensions do perioidcally do this on their own

Thank you for the info.
In that case is it also not allowed to store the jwt in the js file of the extension ?

JWT’s are generated by Twitch.

You can’t store your secret in the extension.

if you generate a JWT (for pubsub broadcast) you can’t store that in the extension as it’s limited life and a secret

I see. Thanks a lot for the help.

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.

if you are using TwitchID’s in your extension the JWT tells you “this is definetly this person”

So up to you

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).


  • 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.

Thank you for the reply.

My system currently works like this:

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.

This step doesn’t work.

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 ?

That’s for oAuth not JWT’s

The question isn’t of compression/data minimization, it’s the number of concurrent/simultaneous connections between the user(s) and your EBS(s)

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.

I have done limited testing in this as nothing I’ve done so far needs bidriation communication in real time over websocket.

I either fan out over Twitch PubSub, or everything is HTTP Posting

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.

This is a work in progress UI: