Pub Sub with fully server side authentification

Hello,

I don’t know if i’m the good category. I’m sorry for my english, i’m french developper.

I developed a Twitch bot that connects to the WebService Pub / Sub. At the authentication level, it is indicated in the documentation that we must use the Oauth Flow to obtain a token access.

On the one hand I was very surprised that it is necessary to obtain an access_token of the concerned Twitch channel directly when one wants for example to listen to the events of moderation while I am, with my account, moderator of the channel in question.

So I had to ask the owner of the channel to fill out an online form which generated an access_token that he sent me.

I would have used the server to server method to get access_token since I have client_id and client_secret but the key obtained did not allow me to use the Pub / Sub service.

So my question is as follows: Do we have to use a “user access tokens” type key to access the Pub / Sub service.

I find this a shame because I usually work with “app access tokens” to query the classic API (New Twitch API).

Yes

As “app access tokens” don’t represent a user. And you need authorization from the broadcaster to read their data.

Any API endpoint (and thus a PubSub topic) that requires a scope, will generally require a user access token, (such as the subscribers endpoint)

Moderators still need permission from the broadcaster to read the subscriber data.

If you refer to the moderation topic see also


wrt to the changes to the moderator topic

First of all thank you for your very quick response.

In this case, can you tell me how long is the user access token generated in this way valid?

I don’t really want to have to contact the owner of the channel every 60 days to ask him to generate a new one. And since I didn’t follow the user feed, I don’t have the expiration date provided.

Expiry is returned when the token is created.

{
  "access_token": "<user access token>",
  "refresh_token": "<refresh token>",
  "expires_in": <number of seconds until the token expires>,
  "scope": ["<your previously listed scope(s)>"],
  "token_type": "bearer"
}

You can also pass a token to the validate endpoint to check it’s expiry

The example response omits the field.

{
  "client_id":"SomeClient",
  "login":"SomeUser",
  "scopes":[arrayofscopes],
  "user_id":"SomeID",
  "expires_in":sometimeinseconds
}

A normal Twitch oAuth User Token is valid for four hours.

You can automate getting a new token using the supplied refresh token

I have a little trouble understanding I will not lie to you.

Two different operations are mixed here. On the one hand obtaining an acces_token which must be done graphically and manually.

So I have to write this acces_token in a hard copy (and if necessary also store the refresh token) so that my application can use it as part of its connection to the Pub / Sub service.

BUT, I must also whenever I use it, use the refresh function, which is completely backend. And the newly generated token access must replace the old access_token in my configuration to be used.

In reality if we follow your logic, I have to store the two keys permanently and have them changed, my program must, on each startup, refresh the access_token so my configuration changes constantly?

Do you understand that we mix frontend operation and backend operation in the same process?

Correct, whenever the user access token dies, you can auto fetch a new access token using the refresh token

Correct!

Yup, that is pretty standard when it comes to oAuth.

  • Get permission from the end user once.
  • Then you run using the token till it dies
  • Refresh that token using the refresh token
  • store the new access token (and new refresh token if one is provided)
  • And use the new token

I store mine in a database generally, and I fetch/save as needed rather than hard coding it

Ok, I understand…

One last question. If I don’t start my program for a while, let’s say several weeks. Will the token refresh function by providing the old + refresh_token, still work?

Generally speaking yes.

Twitch refresh tokens don’t have a published expiry, so should last forever or until the user disconnects your application.

Ok nice,

I’v to store the two tokens for sure in a text file and i go erase it every token refresh with the new tokens… i’v made a little program in node.js, i don’t have a database and i dont want to make too complexe application. I’v just a doubt on the initial config file…

Can i refresh a very old access_token for life or just the more recent given ?

Thankx to you, you’re the best ! :slight_smile:

Should be able to yes as:

Yes but the refresh_token is not enough to get a new acces_token. You also need the previous access_token.

I’m just asking if we can infinitely refresh the very first access_token obtained or should we use the last one we had?

No you don’t

You get a new access token, with the refresh token and your Client Secret. You can lose the access token and still get a new token, if you have the refresh token

POST https://id.twitch.tv/oauth2/token
    --data-urlencode
    ?grant_type=refresh_token
    &refresh_token=<your refresh token>
    &client_id=<your client ID>
    &client_secret=<your client secret>

Oh yes I misunderstood the documentation correctly, I read it and I misunderstood. Sorry.

In this case it is useless that I store the access_token if I understand correctly, I just need to store the refresh_token and ask, each time I start my program, a refresh to use directly and dynamically the access_token provided which changes each time my program starts?

It’s up to you. I store both and validate the token(s) at boot and choose to refresh if the token has < 30 minutes left on it

I specify: My program does not change state once started and does not subscribe to any topic dynamically, everything is done at the beginning and it runs like this for weeks / months.

If in any case it is necessary to call on an API to validate my token, as much to regenerate it directly it goes faster.

It’s up to you.

thank you for everything :slight_smile:

Have a great and nice day ! :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.