Correct, to utilise the API on behalf of a broadcaster you need permission from the data owner, in this case the broadcaster.
The streamer “owns” the rewards and redemptions.
You authenticate/get a token from the streamer once.
This gives you a user token and a refresh token.
When the user token expires, you use the refresh token to get a new token.
if the refresh token dies or becomes invalid, you will need to get the broadcaster to reauthenticate
See this oAuth flow: Getting OAuth Access Tokens | Twitch Developers
Yes, you run a server hosting your Auth service to get a token from the user. Then you can act as the user.
This is an industry standard security mechanism called oAuth.
No auth service? Then no way to get a user token.
Sure you could go the implicit route and have the user copy/paste the token somewhere, but this sort of token cannot be refreshed.
In the <a href="" that the broadcaster clicks on to Authenticate your Applications access to their account
You can see on this implict auth example
https://barrycarlyon.github.io/twitch_misc/authentication/implicit_auth/
There are two links, one that is scopeless and one with the email scope (user:read:email)
If needed you can refer to some examples
I have written two examples for user authentication, one for node and one for PHP
Other examples may exist on Community Resources | Twitch Developers
oAuth is very straight forward
- user comes to your website
- user decides to use your service
- user clicks on a
<a hrefto login (sometimes this might be a/login/that then redirects to Twitch so you can set a state param in the session nicely) - that link takes then to the service
- the user accepts (or declines the link)
- user comes back to your site and if they accepted a
?codewill be present in the query string (other wise an?error/error description) - you exchange the
?codefor an access and refresh token - you store these tokens and use those tokens
This works for a number of serices, you just swap in the different token URL’s and scopes as needed
If I’m building a widget/overlay I don’t use SE. I use all my own stuff.
No need to go via their system if I can build the widget and communication layers myself. It seems excessive to use their system when you built everything else but the communication layer. And I can optimise traffic and communications without being stuck inside their jail.
I don’t need more information on a system I’ll never use when I can build my own.
And this means I can use EventSub or PubSub or the API, I’m not limited to what you can glue together in SE’s widget system. And I can do whatever I need/want to protect the streamers access tokens.
So you cripple yourself and deny your self access to Twitch PubSub and EventSub, if you can only make Get/Post requests.
EventSub is the optimal way to obtain Redemptions in real time. (As will EventSub websocket when it arrives).
PubSub is passable, but I’d wait for EventSub over websockets rather than PubSub here.
I feel users cripple themseleves trying to bend things to work inside other peoples systems.
When it’s easier to just build your own system that dones’t involve making x talk to y. When x speaks english and y speaks french for example.
People get stuck on oAuth and if/when the solve it they spend ages trying to figure out how to glue that into another system like SE when you could save time and build your own without hooking into SE.