Requiring OAuth for Helix Twitch API Endpoints

Announcements
21

I’ve built a number of browser-only applications. It was pretty nice to get something simple up, and perhaps extend to authentication later for api limit or special purposes. Four are in regular use:

Schedule From Videos: published extension that provides a rough broadcaster schedule by querying the recent broadcast vods. This is a panel extensions that should be usable by logged in or logged out users, and I’m unclear how oauth would work here. Maybe I can get some extension stats to see if would even be possible to continue offering this if a server were required.

Hostable: mostly a private app, though it is published, to keep track of streamers I like along with notes (music, swearing, etc) Already has a facility to enter an access token for request rate and other features, so not greatly affected.

Stream Credits: OBS browser scene that shows follows, hosts, etc. With login can show subscribers. Login is there (though awkward in the embedded browser), but token expiration is already a pain. At least when it does expire, the app does something currently.

Hosting Clips: OBS browser scene for BRB etc scenes. Looks up channels hosting me and shows their clips to advertise their channels a bit by way of thanks. The Stream Credits case above shows this is possible, but expiration will be a problem, probably requiring some improvements to better show expiration status and extra items in the go-live checklist to see if the apps need updating.

22

Looks like all your uses cases that currently don’t use a token will continue to work fine if you switch to using an App Access Token, and the lookup is done on a server. Implicit auth may also suffice. The various token types are covered here: https://dev.twitch.tv/docs/authentication/

23

As a developer that has been building applications against the Twitch API for quite a few years now, this announcement really pains me. Not just because it will affect most of my applications, also because it shows how motivated Twitch is to have a vibrant and open API ecosystem (not like helix was a bit of a clue, but we were all hoping for the better, that the Trello board copied from Twitter wasn’t an indication of things to come).

I won’t call this a lie, but I will insist that this is not very forthcoming of the real reasons for this move (I’d love to point out how little this change does for security, but I believe others have already done justice to this argument). Instead, I’ll try to find the real reasons why you’d require OAuth for all API calls. One hypothesis is that it was a challenge to run the IP based rate limiter. Either for privacy or scalability reasons. The other one, that would feel much sourer, is that you have observed that anonymous users of Twitch are fairly unlikely to provide Twitch with any revenue. So the solution to this is to make people sign up more. Or just ignore the platform. After all, what’s a few thousand users lost over better revenue?

I’ll make my final plea, knowing that I can’t change your opinion: I’ve written mostly API clients that interact with the Twitch API anonymously. Why? The most important reason was, that they had no need to be authenticated. This also meant they were accessible to users that did not have a Twitch account, for whatever reasons. I have very little reason to add authentication to those clients because I’d be reducing the feature set. As such, after some of them already losing features from the helix transition I’m really not keen on that. I hear the solution would be to run a server that uses an app token. While true on paper, it also means that I now have to handle the scaling of my application. It also means I have to handle the rate limits of the app token. Oh, and spend money to have a server in the first place.

I’d argue that developer accessibility is less limited on understanding how to use the API without OAuth than being able to build something with little money. I started many of my projects while I was a student and simply couldn’t afford a server that would proxy the API requests. Removing the ability to easily build things against the API would then arguably further lead to less innovation against the platform. But if you want to control the platform you don’t want external innovation, as Twitter showed (and now regrets?).

I guess I’ll focus my time and attention on other platforms like Mixer or YouTube, where you can still interact with the API without user requirement. So long, best API of a streaming site, we’ve had a good run.

(If possible I will of course update my extension to still have working API calls with this new requirement if the appropriate tools are provided, but it’s got barely any calls in the first place, since that data it needs comes from a “grey area”)

1 Like
24

Asking this on behalf of my team…

Would this affect the endpoint

http://tmi.twitch.tv/group/user/${channelName}/chatters

and would non helix (krakken) endpoints with Bearer: Oauth <token are still fine?

25

Hey Swiftor,

The OAuth requirement stated above does not affect the endpoint you mentioned since it’s not in the Helix namespace. However, this is an unsupported API endpoint. I believe there is a discussion about whether or not this functionality should be officially supported in Helix, but there are no announcements at this time.

There are no changes to Kraken endpoint OAuth tokens. The only related product change to be aware of is the new v5 rate limits going into affect this month.

1 Like
26

Many thanks dude!

27

Just to clarify the impact of this - Helix calls are now effectively impossible from the front end?

I have 6 extensions - 3 of which are on the front page right now - and 4 of them will be neutered if they can no longer make client side API calls.

If that is the case, I would have to convert 4 otherwise zero maintenance, zero cost extensions into having a non-zero cost EBS.

My 2 extensions not affected by this are affected by the v5 removal, so, to put it lightly, this sucks.

I’m happy to see feedback has been considered with regards to removing v5, but if Helix calls become impossible from the client side then this will have a much worse impact. I am hoping to see some sort of retcon on this one.

28

Do I understand correctly that this means if we are currently already sending Authorization: Bearer xxxxxxxxxxxxxxxx we will also need to send Client-ID: in the future?

29

Yes send both

1 Like
30

The team has recognized this, hence the reason any Extensions submitted on or before January 31 can continue to use Helix endpoints as-is until June 31. We will have further updates to make this easier for Extension developers before that date.

31

Hey what does that means for the /streams and /users endpoint. I use /streams endpoint with just a user-id of the broadcaster to get the information if the stream is live and /users to get user-id’s by twitch name.

Do you need a token from every user which you want to acquire the user id from by a given user name now? And on top if you want to query if a stream is live you have to provide a user token from the nroadcaster to the client-id of the broadcaster?

This is so unnatural if you are sending user-id’s through IRC chat BUT make them inaccessible through helix. What were your thoughts behind making this?

Am I maybe misinterpreting this all and you only need an OAuth token and the Client-ID of your application?

32

You don’t need to use a User Access Token, you would only need to use a User Access Token on the /users endpoint if you wanted to access privileged data, such as their email address. If you just want to get basic info, on any endpoint that doesn’t require user authorization, you can simply use an App Access Token https://dev.twitch.tv/docs/authentication/getting-tokens-oauth#oauth-client-credentials-flow

You can generate an App Access Token through the Client Credentials flow, it can be done entirely automatically as you don’t need any user interaction like you do with the other flows, and you get the added benefit of having a 800/minute rate limit.

So for example, the /streams endpoint you could query with 100 different user_id= params, and send your Client-ID and an App Access Token that you’ve created and it’ll work fine, you don’t need any of those broadcasters to go through your OAuth flow, and you don’t need use User Access Tokens from them.

33

So user id, for example, is not privileged data?

34

User ID does not require user authentication, as can be seen from the docs example

{
  "data": [{
    "id": "44322889",
    "login": "dallas",
    "display_name": "dallas",
    "type": "staff",
    "broadcaster_type": "",
    "description": "Just a gamer playing games and chatting. :)",
    "profile_image_url": "https://static-cdn.jtvnw.net/jtv_user_pictures/dallas-profile_image-1a2c906ee2c35f12-300x300.png",
    "offline_image_url": "https://static-cdn.jtvnw.net/jtv_user_pictures/dallas-channel_offline_image-1a2c906ee2c35f12-1920x1080.png",
    "view_count": 191836881,
    "email": "login@provider.com"
  }]
}

So if you use a User Access token, the result will include the email field for that user like that example. If you use an App Access Token the email field wont be included but all other fields shown in that example will still be returned.

36

So if i understand you right, i can ‘simply’ use app acces token and now i need to pay money for the hosting of backend and somehow code this backend to only for get basyc data of a stream that has nothing to do with my users of my app? Looks like i’m gonna use kraken until it dies completely.

37

You can use Implicit auth instead. Which doesn’t require the use of a secret.

38

The whole point of my app is to give my user alot of DATA without asking them to do this auth because i am gathering alot of data from different API’s. And now your API giving me no choise or i do it myself on the srver side instead of my users or ask my users to do what i don’t want them to do.

39

Twitch has decided to make the change. Not me, assuming thats who you mean by “your”

It is what is it. Using an auth is a good idea anyway as you get the higher rate limit, 800, over the unauth’ed 30

40

The Implicit auth flow is simple to implement if you wish to remaining do this entirely client-side.

If you don’t wish to request your users go through an auth flow then yes you are going to need some form of backend server, which will also have the added advantages that come with it such as greater control over requests and caching.

This is a good change as it provides Twitch greater control over restricting access to malicious apps, or ones breaking the ToS and misusing data, which is more difficult to control when requests only required a client-id which is public.

41

Good for who? Me ? I don’t know ho to do server side and i am not ready to pay for hosting eather. I think alot of noob programmers will just drop this API too but looks like Twitch actualy want this. Asking my users to log in not an option. Looks like the only way is to stay on old API and then migrate to other stream services without this OAuth bs.