Getting client ID for PubSub

[Haaldor]

This probably is very stupid question and surely feels like it should have been asked already multiple times, somehow though haven’t seen it yet… And after hours and hours of googling and searching this forum I’m still left out dry like a fish on the desert, I’m just gonna ask:

How does one get channel ID of user A, having access to:

• User’s B channel name;
• User’s B oauth;
• User’s A channel name;

Where user B has all possible access to User’s A channel (is a mod and everything).
 

To draw the picture a little bit:
I’m making Chatbot written in gdscript, that needs to also listen to channel point redemptions. That’s basically it.
For normal chat interaction, those three things mentioned above are enough.

Only possibility I found for getting Channel Points Redemtions and other related events is PubSub.
As both normal chat interaction and PubSub are based on Websockets, it’s pretty easy; Issue is, to connect with PubSub I need this mystical information named “client ID”… And here’s where issue rises.

From what I found, to get client ID I have to use http request to

https://api.twitch.tv/helix/users?login=userAlogin

Well, alright - had to do some workarounds but managed to get get websockets and http request together somehow. But the request requires me to input oauth (fair enough, we have User’s B oauth token so can do) and client id… which makes no sense, to have to have client ID to get client ID.

It’s important for my chatbot to be flexible and user friendly, so I can’t be dependent on using one particular bot or channel account and all three pieces of information mentioned at the start of this post are inputted by user, so can’t be hard-coded.

So, summing up - is there a way to get client ID of user, knowing his username?

Sorry for the long post and thanks for all help!

[Dist]

@Haaldor

So, summing up - is there a way to get client ID of user, knowing his username?

Users’s don’t have a client ID. A client ID represents an application.

You should register your application Authentication | Twitch Developers and then using the credentials for that application you can have users go through your apps OAuth flow, or create App Access Tokens for any API endpoint that doesn’t require user scopes.

That Client ID for your app you’ll use for ALL of your requests, regardless of which user you’re requesting data for.

If you want to get a user id, you can use the Get Users endpoint Reference | Twitch Developers with any OAuth token, be it a User Token, or an App Token, as that endpoint doesn’t require user scopes (unless you need a users email, in which case you do need a user token from that user).

[Haaldor]

Thanks for the quick answer!
Taken I don’t want to pull user through authentication at all, I’m guessing I should use 2nd option you mentioned:

@Dist

If you want to get a user id, you can use the Get Users endpoint Reference | Twitch Developers with any OAuth token, be it a User Token, or an App Token, as that endpoint doesn’t require user scopes.

However, as I mentioned it, I tried it already and when using User B’s oauth, it responded with “Client ID is missing”.
When I created the app (leaving redirection to “https://localhost”, because noone should ever authorize there or go into any links) and copied the Client ID, it throws error “Client ID and OAuth token do not match”, so still not that.

So I don’t see how I can do it with just User B’s oauth token without sending anyone through authorization, as you proposed…

[Dist]

If you’re getting a “Client ID and OAuth token do not match” error, it’s because you’re not using an OAuth token generated by your app.

You need to register an app on the TwitchDev portal, that’ll get you a Client ID. Then if you’re making requests server-side you should use the Client Credentials flow to generate an App token.

If you generate tokens using any other site, or anything other than your own client id, you’ll get a mismatch error.

If you want to use User B’s OAuth token, then it’s exactly the same except you’ll send User B through your apps OAuth flow, with Implicit or Auth Code depending on situation, to get an OAuth token from that user. Again, it has to be your apps OAuth flow, and your apps Client ID.

[Haaldor]

So as I understand, there’s no way to make normal app (like classic .exe chatbot or simply a game) that can access channel’s Points Rewards with just username and oauth without the hell of pulling user through authentication etc

It’s not a solution, but it is answer nonetheless - let’s just hope system will be improved someday to allow for more.

Anyway, thank you for your time and will to help!

[BarryCarlyon]

@Haaldor

with just username and oauth without the hell of pulling user through authentication etc

To get an oAuth Token for a USER, involves an Authentication loop using a ClientID in the first place.

@Haaldor

(like classic .exe chatbot or simply a game)

For a .exe then probably looking at implicit auth which doesn’t require leaking your secret.
Course that still needs a webserver to collect the token
Or a website the user gets sent to with an instruction to copy/paste the token.

or the .exe connects to your server via some method and the server handles the relay/auth stuff.

@Haaldor

simply a game

Some games on twitch have in the past use an anonomous bot (no token needed) or implement oAuth to obtain account access, which method varies by implementation.

@Haaldor

So as I understand, there’s no way to make normal app (like classic .exe chatbot or simply a game) that can access channel’s Points Rewards with just username and oauth without the hell of pulling user through authentication etc

Channel Points is “privileged” data.
So you need a USER oAuth token with the relevant scopes for the user/broadcaster in question, since you need permission from the broadcaster to read/write to their account.

Sure here you could use EventSub but that at the moment only has a webhook transport (socket on the way), so you’d need a relay server to capture events and relay to the game/.exe in question. Then all auth is handled on your server and the .exe/game takes to the server.

So you don’t handle Twitch Auth “in the app” but via another method.

App → talks to your server via some method to ID the App
Link that ID to a TwitchID + token in your database

@Haaldor

It’s not a solution, but it is answer nonetheless - let’s just hope system will be improved someday to allow for more.

Not sure what you are expecting to improve here, since “permission” is needed for priviledged data, so an oAuth loop is required in order to obtain that permission.

[Haaldor]

@BarryCarlyon

Then all auth is handled on your server and the .exe/game takes to the server.

That’s the issue - one of main ideas of this app (and other apps in future for me) is that they have to be standalone, meaning - no server, no website, just app using only webhooks and/or html request.

@BarryCarlyon

Some games on twitch have in the past use an anonomous bot

Yeah, that I know of and was thinking about it. However it doesn’t give possibility of interacting with channel points, which is the issue here.

@BarryCarlyon

Not sure what you are expecting to improve here, since “permission” is needed for priviledged data, so an oAuth loop is required in order to obtain that permission.

Up to this point I used twitchapps tmi site (as instructed on guide site) to generate oauth and manually paste it in the program along with username - in my opinion it’s much more readable and intuitive (however it’s true it would feel even more readable and polished if oauth token would be generated in Twitch user settings and just be copied from there).
Main issue is though how troublesome is Authorising every program every hour or so, making me - as a user - eternally hate two factor login.
System that would allow user to get oauth once and app to just use it would help both users and developers so much - this is why for now I’m trying to not dip into Authentication hell.

[BarryCarlyon]

@Haaldor

Up to this point I used twitchapps tmi site (as instructed on guide site) to generate oauth and manually paste it in the program along with username - in my opinion it’s much more readable and intuitive (however it’s true it would feel even more readable and polished if oauth token would be generated in Twitch user settings and just be copied from there).

That works if instead of using their site your use your own site.

Then the user copy/pastes the token from your ClientID site to the app.

You shouldn’t rely on someone elses clientID, since if it dies/removed/revoked poof goes all your tokens.

In this example, you’d have to provide a new token every 60 days since it can’t be refreshed.

@Haaldor

(however it’s true it would feel even more readable and polished if oauth token would be generated in Twitch user settings and just be copied from there).

That in theory is a security issue, since it’s essentially a “password” so if someone obtains it thats difficult to revoke. Even more so if it’s a “forver” token like what I think you are proposing here. And you would have no idea who else could be using that token, which would reduce the rate limit that could be able availble to your app, and if the same token is in use from multiple IP’s that looks like a security issue. (If Twitch audits and goes “somethings awry”)

@Haaldor

Main issue is though how troublesome is Authorising every program every hour or so, making me - as a user - eternally hate two factor login.

It shouldn’t prompt every hour…

A “normal” user token is good for 4 hours and you can refresh it automatically (but that needs the client secret which can’t be in a desktop app).
An implict user token is good for 60 days (generally) but can’t be auto remade.

[Haaldor]

@BarryCarlyon

That works if instead of using their site your use your own site.

That would mean spending money though, which is quite a requirement for non-profit devs/streamers.

@BarryCarlyon

You shouldn’t rely on someone elses clientID, since if it dies/removed/revoked poof goes all your tokens.

Absolutely - that’s why whole clientID system is quite counter-intuitive.

@BarryCarlyon

Even more so if it’s a “forver” token like what I think you are proposing here.

I see what you mean by security reasons here, and well - fair enough.
What I had in my eyes was just a Authorisation page in settings with table somewhat like this:

Name	Oauth token	More info	Remove?
Streamlabs	**************************************	[show]	[X]
StreamElements	**************************************	[show]	[X]
That funny app with timer	**************************************	[show]	[X]
My own app 1	**************************************	[show]	[X]
CREATE NEW OAUTH

Where you can either use already created oauth somewhere or you can create new one with your custom name and custom scopes (visible after clicking “More info” button, along with other possible information like how old is oauth, when it was last used etc, whatever possible and wanted).
Taken many (if not most, what would be my wild guess) users don’t even know they can revoke oauth access and don’t remember what apps they give their access to, this would allow for much more control and higher feeling of security (not even mentioning looking much more professional). And also - “forever” tokens would make life so much easier for both devs and users, that’s for sure.
One of reasons I started writing my own bot was my absolute bottomless hatred for having to re-authorize Streamlabs every time (sometimes every day, sometimes once a week, still - pain in the wrong place).

@BarryCarlyon

It shouldn’t prompt every hour…

Well, that’s what sometimes happening, but to not overreact and be fair - it’s quite random. While I was making this bot I had to re-authorise it 3 times in one day, and other time it lasted few days.
With streamlabs chatbot it’s also random, but on average have to re-authorise every week - sometimes everyday, sometimes it will last for month.
It might be only ~5 mins everytime it happens, but when it happens right as the stream is starting, it’s surely a setback right at the start.

But also, thanks for the talk, I feel like I got to understand authorisation system a bit more now, even though it’s still super confusing.

[BarryCarlyon]

@Haaldor

Well, that’s what sometimes happening, but to not overreact and be fair - it’s quite random. While I was making this bot I had to re-authorise it 3 times in one day, and other time it lasted few days.

What could be happening is the “token generation limit”

If the same broadcaster is generating new tokens using “TMI token gen” an app you don’t control. For some reason. Every 25 tokens it will kill the first token (by age).

Which is another reason for not using someone elses token generator, becuase you don’t control the authentication process.

@Haaldor

I see what you mean by security reasons here, and well - fair enough.
What I had in my eyes was just a Authorisation page in settings with table somewhat like this:

Name	Oauth token	More info	Remove?
Streamlabs	**************************************	[show]
StreamElements	**************************************	[show]
That funny app with timer	**************************************	[show]
My own app 1	**************************************	[show]
CREATE NEW OAUTH

Then this ends up in you generating a token for SE/SL (for example) with the wrong scopes on since you could generate a “incomplete”/scope limited token for the apps needs using the “Twitch Console/settings page”

Since Twitch doesn’t know what scopes an App needs.