Requiring OAuth for Helix Twitch API Endpoints

Announcements
1

In an effort to standardize authentication and provide security improvements for the Twitch community, OAuth will soon be required for all Twitch API endpoints in the new Twitch API, also known as “Helix.” The goal of this announcement is to provide a timeline, full details of this new requirement, and answer a few anticipated questions. Please feel free to add further questions via the comments below and we appreciate your feedback during this process.

Update (2020/06/02): See “How will this affect Extensions developers?” below.

Update (2020/04/21): We have changed the first scheduled window from April 30 to May 1.

Update (2020/04/20): To help developers with awareness of the OAuth requirements and confirmation that their applications meet the requirements, we are implementing scheduled windows when the requirements will be enforced. Please see the section below entitled, “When and how is this change happening?” with the full schedule that will begin on April 30 and conclude on May 11.

What’s changing?
Starting on May 1, 2020, Helix will require the following:

  • Use of OAuth across all endpoints, either via an app access token or user access token.
  • The client ID provided in the corresponding header must match the client ID used to generate the OAuth token.

Here is a sample request to show the headers mentioned above.

curl -H 'Authorization: Bearer cfabdegwdoklmawdzdo98xt2fo512y' \
-H 'Client-ID: uo6dggojyb8d6soh92zknwmi5ej1q2' \
-X GET 'https://api.twitch.tv/helix/users?id=44322889'

When and how is this change happening?
Starting on May 1, we will begin implementing scheduled requirement windows based on the points above and the permanent requirement will go into effect on May 11, 2020. If your application does not meet the requirements above, it will experience 401 error responses during each window and permanently on May 11. The expected scheduled requirement windows are as follows:

Why is Twitch making these changes?
As part of our goal to provide a unified high-caliber API experience to developers, we are providing a more consistent and controlled means of access to the Twitch API.

How will this affect Extensions developers?

Update (2020/06/02): Extensions submitted for review on or before January 31, 2020 can continue to use Helix endpoints as-is for the foreseeable future. We are still exploring ways to provide the same functionality with OAuth requirements, though we do not have a date or timeline at this time. The text below has been updated with strikeouts to reflect this.

Existing Extensions submitted for review on or before January 31, 2020 can continue to use any Helix endpoints as-is until June 31, 2020. These Extensions will need to be updated and adhere to the new OAuth requirements above by this date. New Extensions submitted for review on or after February 1, 2020 will need to use OAuth to access any Helix endpoints.

We are actively exploring methods to allow Extensions to have some of the same functionality developers currently have through the front-end without an OAuth token. It is currently in ideation stages and we will have more information before the date in June.

Where can I learn more about the use of OAuth on Twitch?
Please refer to the Authentication section of the Twitch Developer documentation.

What happens if I don’t pass an OAuth token in my API request?
You will receive a 401 error in response noting that you must pass a valid OAuth token.

What happens if the client ID in the header of my request does not match the client ID in my OAuth token?
You will receive a 401 error in response noting that your pair of client IDs do not match.

My application does not currently make use of an OAuth token to access the Twitch API. What should I do?
We recommend passing an app access token within your request or a user token for a request made on behalf of a Twitch user. In addition to the authentication documentation, you can learn more about these options in our blog post entitled Authentication: Understanding Which Protocol and Flow is Right For You.

We also recommend that you do not use an app access token in your frontend development. This should be handled by a back-end server for the security of your application.

How will this change the Twitch API rate limits?
The Twitch API rate limits are currently based on either IP address for unauthenticated requests or OAuth tokens for those requiring authentication. After these changes, access to the API will only be available via OAuth tokens and rate limits will no longer be based on IP address.

As mentioned, please provide any questions you may have below; we appreciate your feedback related to this authentication change.

3 Likes
2

Extensions will not be able to perform ClientSide calls to Helix.

For example, JWT provides userID, but not username/display name.

So currently I have extensions that do a client side request to the users endpoint. This will no longer be possible with this change.

Basically any Extension that doesn’t have an EBS cannot get ausers username or display name, or other public profile data

And many extensions with an EBS do this anyway, to save not having to EBS relay that request.

I literally put an extension into review yesterday, that doens’t use an EBS, but makes one call to helix to get the broadcasters Name from ID in the config panel. I now need an EBS for that extension for that single call.

2 Likes
3

As Barry mentioned, this is a significant change for extensions. The result will be either reduced functionality in those extensions due to not being able to perform client-side requests, for extensions where those requests are essential this now means an EBS is required which will increase costs or potentially cause some developers to retire the extension entirely rather than deploying an entire EBS infrastructure.

Is a client ID header not redundant? Anyone who has an OAuth token can determine the client ID used to generate it, so this in no way provides any measure of security and only means to add additional (albeit tiny) overhead with this redundant header. I’m just curious what this is actually intended to accomplish as to determine if the client ID matches the OAuth token Twitch must be doing some lookup internally, so if it knows the ‘correct’ client, why ask us for it?

4

Yeah it doesn’t prevent theft of an app access token, as an app access token can be verified and it’s clientID obtained from the validate endpoint

curl -H "Authorization: OAuth <access token>" https://id.twitch.tv/oauth2/validate

You call validate and get the right clientID and remake your request…

5

To go along with the previous comments, if the Extension helper would provide a token upon giving access, that would resolve these issues. If we get an additional field on the onAuthorized object with the token, this would provide the needed requirements. You don’t need to give any scoped access, just a generic token for extension use for requests.

1 Like
6

100% agree with all the comments above. This a huge issue for us extension and being able to cost-effectively run our extensions. To @WLG3R recommendation, please provide extension with a mechanism to get a token when receiving the onAuthorized event.

7

Extension will need a system to be able to do calls without the need of an ebs. I do have multiple extension that do not use an EBS and it would be annoying to add one.
What will happen is that you will see some caching server popping around. They will be used to go around these limits for public information for like user info , stream status, etc. But it will cost money, and time and requires knowledge.
So it will create a break in the community.

And this will exclude newcomers and beginners from the Twitch ecosystem.
One of Twitch strength was how easy it was to use the API. Now if you just want to get the username you will have to learn Oauth which can be really difficult for new devs.
This remove the cases where people can learn to code with Twitch. Like hackathons, small website used as tools, chrome extensions, etc
Many people do not know how Oauth works and it can be really complicated to understand at first.

With this we are losing a lot of people that could have joined the community and used Twitch products.

Some of my tools do not use an Oauth flow because they take like 10 lines of javascript, adding Oauth flow would be more complex than making the API call

Please reconsider this decision, add more limitions to the data, but this will arm the community and the creation of apps with twitch products.

3 Likes
8

I wanted to provide a couple of examples of how this is going to negatively impact myself developing Twitch extensions.

Example 1:
I am using a cron job running in lambda that is updating data via the Twitch API. This is not a stateful server and env variables are pulled in on every call. My current setup for loading the env vars does not allow me to update them, so now I must move all, or at the very least implement some new method to store an oauth token for API calls. I also must now have some way to refresh that token every so often and update the stored oauth token or risk the entire setup breaking. If something prevents the oauth refresh call, I now risk my server being unable to make API calls at all. This also means I can’t rely on a refresh working and need to update my oauth token fairly frequently in case of a network failure. Since refreshing the token requires an existing active token, if the token expires without being refreshed, I now have to manually go through an oauth flow, and update my saved token manually so that it will work on the next run (and probably add some alerting method as well).

This would similarly impact services built around microservices / serverless architecture like api gateway.

Example 2:
We are currently allowed to send an extension client id rather than an app id in the headers. This means you now need to handle this oauth refresh flow for multiple client ids if you utilize both the extension client id, and an app id.

Example 3:
I’m currently developing an extension that is a couple of days (at most) from being ready to send for review. I am now being given 1 days notice to make substantial changes to how the API calls are being handled. I don’t think I need to point out how painful this is.

As a side note, I hope that you will provide more time when sunsetting the v5 API. There is still a lot missing to hit feature parity between it and Helix, and would hate to see a similarly short notification for that.

9

I will also point out that that ethically it is not a great change.
In a world where the dev community tries to reduce its energy impact by lowering server charge and traffic, forcing more web requests isn’t a great message sent to the rest of the world.

Now we will have to make more calls to oauth, and/or more calls to caching servers, duplicating storage and api calls to reach a caching server that then reach twitch api

1 Like
10

I echo all the things mentioned above.

And for the more official way, lets vote this up. https://twitch.uservoice.com/forums/310213-developers/suggestions/39577891-cancel-the-new-oauth-for-helix-requirements

2 Likes
11

These changes seems nice overall, actually. It seems like the only thing at least from what I can think of is that a public read-only API that doesn’t require OAuth to query users and streams seems pretty crucial and not having that complicates building for Twitch quite a bit. Helix is still missing the ability to know what game or stream title a streamer had set last unless they’re currently actively streaming, and then requiring authorization to even just look up users and profile info makes not just extensions but stream overlays and static featured stream team sites a tougher and more costly problem. As long as there’s some non-authenticated way to query basic info, I think this change would be great.

12

Extensions have their own ClientID and ClientSecret.

There is no need to run a seperate set of ClientIDs/Secrets/oAuth Redirects from an “Application” as an “Extension” is also an “Application”

Example 2 seems invalid.

Dev → Console → Manage Extension → Extension Settings

It’s all there:

image
image1338×1375 95.8 KB

13

Will there be required scopes added to access each endpoint that current doesn’t require authentication? If not, this change seems excessive and just introduces more overhead. Even outside of all the valid extension point of views mentioned above, I’m failing to see how this will increase security. This comes from the fact that if you do have a valid OAuth token, as @BarryCarlyon and @Dist mentioned, you can always just validate the token to get the proper client ID.

Also, if this change does stick and OAuth tokens are required across all endpoint, will it be required that a client ID is paired with the token? “Security” reasons aside, that is completely redundant since that information can be determined from the provided OAuth token.

14

This is a good change and I am in support of this direction, but I would recommend extending your deprecation period a bit as this is quite a substantial, disruptive shift from how Twitch’s API operated previously. There are potentially many implementations which do not perform authentication against OAuth2 (for both app access tokens and user access tokens), instead relying solely on a client ID for accessing Twitch data.

15

I agree, even for apps that do use OAuth user tokens, if they don’t already send a Client-ID header too in addition to the token those apps would break too. Obviously much easier to fix but there are probably a ton of devs that will miss this announcement and have broken apps that day.

Doing a temporary rollout like with the v3 to v5 change might be nice, where it was active for an hour, then a couple hours, then a day and permanent, over the course of a week or so.

Apart from the thing where requiring a Client-ID header is redundant anyway since you can get the Client ID from any token already but hey ¯\(ツ)/¯

16

Sorry if I was unclear here. Let’s say you have a website that pairs with the extension. IMO it does not make sense to use the extension client id for that website, but instead use a separate app for that with a separate client id. Especially if that website could potentially live on its own after the life of the extension.

Another thing that comes to mind is that all OAuth libraries that currently work with Twitch are now going to be broken. Passport and Goth would be two in particular that come to mind but I am sure there are many implementations for each coding language. They both rely on sending the OAuth token as the bearer token to retrieve the user information after a successful handshake. Those currently have no way to specify a client id as well and would require pull requests. In some cases these might be major changes (I have not specifically looked into what this change would require in them). So every website that uses Twitch OAuth and Helix to get the user information are now just going to be broken.

The Helix endpoint for getting users even specifically returns the error:

{
“error”: “Unauthorized”,
“status”: 401,
“message”: “Must provide a valid Client-ID or OAuth token”
}

Let me repeat this: Every website that uses Twitch login will be broken.

17

I suppose so. But if the keys still work with no released version should be fine.

But the website(s) that go with my extension(s) all use the Extension ClientID/Secret rather than Credential juggling,

(And we probably need/want Twitch to add a button to convert an Extension to a “pure” Application, which would negate the issue you are describing and the need to credential juggle)

Additionally having two sets of keys, means that for a broadcaster to “leave” your extension they have to deauthorise the extension (easily done on uninstall), and then have to manually go an unlink your second set of keys, which they may also never do. Two sets of keys is impractical for an extension (in my opinion) and a base usage.

Side note: if this works for you and your flow. That’s fine, I just think it’s super convoluted as a work flow.

Submit a PR, the passport “official” one is super out of date, and the one we tell people to use on the Discord is a fork.

PR should be pretty small to add a ClientID to the calls since the ClientID is used in the oAuth loop, and the step immeditely prior to fetching userdata (the access token exchange)

image

Calling https://api.twitch.tv/helix/users with an access token doesn’t 401 for me at time of writing. Whats the call you are actually making here?

18

This change will impact me in two ways:

  1. I have an extension with no EBS that gets users from helix. Under this model I would be required to implement a backend serving a hefty amount of traffic.
  2. I have an extension in progress which requires access to streamer information without relying on the EBS.

Seems counter intuitive to lower the barrier by including a configuration service but then raise it again without making api calls. I trust that as the extension api endpoints are not helix they are unaffected? If you absolutely must close off these end points, please allow this information to be retrievable through the extension helper / extension api endpoint.

Thanks

19

Hi everyone, I wanted to acknowledge the posts above and that we appreciate all of the feedback, suggestions, and use cases provided. This is exactly the conversation we were expecting. I’ll be reading through these comments today in more detail, distilling points for the API team, and answering any questions I can up front. I expect many of the points will require some discussion with the team and then followup next week. Thanks for your patience.

5 Likes
20

I should also confirm that we are aware of the challenges this can cause for Extension developers. This is the reason we have created an extended timeline for these client IDs as we devise proper solutions for Extensions.

2 Likes