Question about Extension Secret and Application Secret keys

Game Development
1

Been a couple of years since I have done anything with my EBS and Frontend Extension due to life getting in the way, but now back and I have a few questions.

While I had lost / misplaced all my previous code for the Frontend and Backend I still have a rough idea how it worked.

I will be having a Frontend Extension that will be a Video Overlay where the viewers will interact with the game that the streamer is playing live on stream.

I will also have a Extension Backend Service (EBS) running on my server that receives interactions from the viewers periodically where it sends it to the Game in question and any response gets sent back to the viewers Frontend via PubSub.

I am already able to have the viewer prompted to accept the permissions to get the public User-ID and its sent to my EBS where it validates the JWT.

Now I am stuck getting the Public display_name due to it requires an Access Token and it requires the client_id and client_secret, sadly it says the client_secret is invalid due to it is a long base64 string. If I base64 decode it and use that it fails badly.

Like I said that client_secret is fine for signing and verifying the JWT and the PubSub stuff, but not for getting a token to call “https://api.twitch.tv/helix/users”

My questions are the following:

  1. Do I need to create both an Application (for EBS) and an Extension (for Frontend) to do the above?
  2. If only the extension is required for the Frontend, how do I get the Access Token so that my EBS can do requests to get i.e. display_name ? I know that the EBS uses the Extension Secret to sign the JWT to be used as the Bearer along with its Client-ID to send PubSub messages. But I just cannot do any user lookup’s.

Or am I going all about this all wrong?

Thanks in advance

Paul

2

Oh my bad I was blind LOL.

Seems that I didn’t see that the Extension has a Client ID, Extension Secret and a "Client Secret".

I didn’t see the Client Secret section due to it was blank (i.e. hidden for security) so I just created a new Client Secret and I was able to request for a Token.

I thought that there were 2 Secret Keys, but it had been ages since I last touched the code.

So that answered my 2 questions.

3

You can use the newish helix token that a front end provides, pass that up to the EBS and use it (or do it in the front end)

see Using the Twitch API in an Extension Front End | Twitch Developers

So if your frontend passes up the helixToken to the backend then your EBS doesn’t need to hold on to or maintain a regular Twitch API token, and you can ditch utilizing a client secret and a generated app access token.

I’ll answer your questions as well for clairty of others whom find this post

No, an extension is also an application.

An extension will have two secrets, one for JWT operations (found under Extension Client Configuration commonly ends with an =) and one for API operations/user or app access token generation (called Twitch API Client Secret in the UI)

The Twitch API Client Secret is only shown to you once when it is created.

Either utilise the helixToken as noted at the start of this reply or generate an App Access Token using the right secret.

4

Yeah, I got it all working tonight with the EBS as a Web Service due to the EBS is / will be lightweight and just passing messages. The token I get along with the Viewers Public Info within the EBS once I found the Twitch API Client Secret LOL You always find it after posting LOL

I haven’t yet put in the Sending of PubSub Messages in the EBS as yet, its sent via a web page atm I wanted to keep everything separate while I test what works or not. So the channel_id and broadcaster_id are currently hard coded to my channel.

Yeah I agree with the two secrets where the Extension Client Configuration which is Base64 Encoded which you have to remove the = at the end if it needed padding etc if you wanted to test the JWT (https://www.jwt.io/), which confused me a bit at the start and it was only trial by error that I got it working. But yeah it was the Twitch API Client Secret that stumped me until I took a deep look at that page and saw it (major slap on forehead moment) LOL

To be fair I did try both the token as well as the helix token provided once they had authenticated on the Frontend, neither worked for me at the time, but also to be fair it might have been my code at the time.

But while some parts of my code are separate, they do all work together. So I will be putting code into classes and remove redundant code etc. I will also retry the helixToken way that gets passed to the EBS and see if that route now works.

I know I am currently using Redis to store the Access Token, so it only needs to requests for it the once and then when its near expiration (think 60 days?).

Once again thank you for the reply.

Regards
Paul

5

You shouldn’t remove the =

The helixToken you need to prefix with Extension not Bearer

Yeah App Access’s are around 60 days give or take a few hours/days.

6

Oh I know, I was just referring to when you test the jwt (header + payload + signature) on the JWT Site (https://www.jwt.io/). You leave it on in your code.

Yeah I also tried that, but when I tried it I didn’t have fully working code at the time.

Yeah I thought it was ~60 days. I might aim for every 8 weeks (gives ~4 days buffer) unless it fails a request if our server rebooted and/or we lost the cached Token. But I should be fine.

— update —
I just checked using the window.Twitch.ext.viewer.helixToken (i.e. viewer.helixToken) after they had authenticated and window.Twitch.ext.viewer.isLinked (i.e. viewer.isLinked) is true and it worked fine. So I now don’t need to request and store the access token for now.

Once again thanks for the reply.

Paul